page 1 1 Introduction The PLATO Configuration Handbook describes the method of configuring the PLATO application. Other documentation for the PLATO application can be found in the: PLATO Operations Guide SMD 133345 PLATO Installation Guide SMD 133346 PLATO Configuration Handbook SMD 133347 PLATO Software Release Bulletin SMD 133348 This handbook is divided into two major sections. - a description of configuration parameters and procedures which are common to all systems - several appendices, each of which describes configuration parameters and procedures for features of the PLATO application which are only used on a few systems. page 2 2 Deadstart File This section describes only those things which are unique to deadstart files used with the PLATO application. In all other respects, NOS standards, as described in the NOS Analysis Handbook, are followed. page 3 2.1 CMRDECKs There are currently no changes needed to CMRDECKs to support the PLATO system. page 4 2.2 EQPDECKs The following are required EQPDECK entries for systems using the PLATO application. 1. All EQPDECKs must contain the following entries to define the mass storage device where the account log, system dayfile, error log, and maintenance log are placed: ACCOUNT DAYFILE ERRLOG MAINLOG These are necessary to prevent the system from defaulting to the first mass storage device, which will always be the Extended Memory (EM) device for systems running the PLATO application. These system logs will interfere with the PLATO application if they are placed in EM. This will result in error messages from PP/MXX such as "local file error" or "track allocation error" when attempting to load PLATO, or in a reduced amount of EM being assigned to the MASTOR control point. Note also that allowing other uses of EM may also interfere with the PLATO application. These include using EM as an alternate system residence device, a temporary file device, a rollout file device, a checkpoint file device or a PF device. If User Extended Memory (UEM) is allocated, the "rax" and "flx" entries in the PLATO configuration file may have to be adjusted. This is due to the fact that the PLATO application reserves all of its needed EM tracks at load time, and also because the EM tracks must be in sequential order. If NOS is making use of EM for some reason, there may be reserved tracks between the first track the PLATO application requests and reserves, and the last track it requests. Generally this will result in PP/MXX issuing a "track allocation error" message and then aborting. It may be possible to get around this situation if use of EM by other than the PLATO application is necessary by using the MSAL console command to restrict further usage of EM, and then waiting for current users to leave (e.g., allow rolled out jobs to roll in), before trying to load or reload the PLATO application. 2. As part of the NOS RMS RAM Enhancement feature of NOS 2.4.2 level 642, the THRESHOLD command was added to the EQPDECK. The important aspect of this command for PLATO sites is that NOS monitors disk packs for low space and issues a "SEE A,OPERATOR" message when a disk pack goes below the low space thresholds. Since PLATO disk packs are normally very low in free space, sites should enter THRESHOLD commands for all PLATO disk equipments. Both the RA and LS parameters of the command should be set to zero. See page 5 the Features Notes for this release or the NOS Analysis Handbook for more information on this command. 2.2.1 EQPDECKs CYBER 170-800 series mainframes require only the above EQPDECK entries and the DE EQPDECK entry used to describe the EM device for the proper operation of the PLATO application. The following describes EQPDECK entries for devices commonly used on PLATO systems running on CYBER 170-700 mainframes only. These are in addition to the entries described above. These parameters are used: ord = One- to three-digit octal Equipment Status Table (EST) ordinal of equipment st = (status) ON or OFF (usually ON) eq = (equipment) Controller number (may vary with each system, the most commonly used number is shown) un = Unit number (for most entries, this is not applicable, so use 0) ch = One- or two-digit octal number of the channel to which the equipment is connected 1. SHARED LOW-SPEED PORT / DDP This entry defines a DDP or low-speed port for use by PP programs MRQ, PMS and MAS. EQord=D1,ST=st,EQ=5,UN=un,CH=ch. This entry is optional, but is normally used to improve performance. If the D1 entry is not used, the PLATO configuration file parameter "ncmb" must be greater than zero. This is to allow the PLATO disk driver (PMS) to perform disk transfers through a Central Memory (CM) buffer instead of through the low-speed/DDP port. 2. ESM SIDE-DOOR PORT This entry is used only when using Extended Semiconductor Memory (ESM) as the EM device. EQord=SP,ST=st,EQ=1,UN=un,CH=ch. Prior to NOS 2.1, ESM error monitoring on PLATO systems was only performed by program ESM. Now, there are two options for ESM error monitoring. page 6 a. Use the SP EST entry as described above. This identifies the ESM maintenance channel and allows program ESM to be used for error monitoring. b. Use the MC parameter on the ESM EST entry (DE). This allows the operating system to perform error monitoring. Refer to the NOS V2 System Analysis Handbook for more information. Also, read the section on "ESM Management" in this Handbook before choosing the method of error monitoring to be used on your system. page 7 2.3 LIBDECKs The following is a list of LIBDECK entries required for the PLATO application. See the PLATO Operations Guide for more information on the following procedures. These entries are delivered with the initial release of the PLATO application and placed in file LIBDIR under the PLATO user name by the installation procedures. *cm pp/mas *cm pp/4qf,4qg,4qh,4qi,4qj,4qk (mrq) *cm pp/4ql,4qm,4qn,4qo,4qp,4qq (mrq) *cm pp/4qr,4qs,4qt (mrq) *cm pp/4qu (mrq - 700 series mainframes only) *cm pp/4pa,4pb (pms) *proc setpun (set plato user name) *proc versx (version load) *proc configx (get config) *proc mfnx (attach master files) *proc platx (load plato executor) *proc framx (load framat) *proc pnix (load pni) *proc condx (load condensor) *proc formcmd (format cm dump) *proc emdtape (dump em for plato) *proc copypd (copy plato dump) *proc dumpprt (print cm dump) *proc emprt (print em dump) *proc pdcat (catalog plato dump) *proc mftload (copy mf to disk) *proc mftcopy (copy mf to tape) *proc mfpack (mf pack utility) *proc bkstart (backups) *proc backdmp (backups) *proc mfdx (backups) *proc recoval (recover master files) *proc recovmf (recover master file) *proc pafterm (daily raf processor) *proc endofbc (monthly bc processor) *proc z1daily (daily acct sum processor) *proc z1endbc (monthly acct sum processor) *proc pcdconv (pcd3 uploader) page 8 2.4 IPRDECKs The following are required IPRDECK entries for systems using the PLATO application. 1. An "ENABLE,SCP." entry must be present to enable the system control point facility if the PLATO ASCII network is to be used on your system. 2. An "ENABLE,PLA,cp." entry must be present in the IPRDECK to specify "cp" as the control point where MASTOR will be loaded by the operating system when the "PLATO." DSD command is entered at the computer console. The PLATO application occupies this control point and the following four control points. To minimize storage moves of the programs which make up the PLATO application, it is recommended that you use the following control point configuration: 1. IAF (must be at control point 1) 2. NAM (controlled by ENABLE,NAM,cp. entry) 3. MAS1 (controlled by ENABLE,PLA,cp. entry) 4. PLA1 (controlled by submit file PLATOD) 5. FOR1 (controlled by submit file PLATOD) 6. PNI1 (controlled by submit file PLATOD) 7. COA1 (controlled by submit file PLATOD) 3. A "DELAY" entry must be used to change the default values of the CPU recall time parameters. The following recommendations should be considered when setting the value of the "CR" parameter on the "DELAY" entry. - Sites for which batch processing time is not a cri- tical and/or scarce resource should use a setting of 15B milliseconds. - Single-CPU sites which use NAM for part or all of their communications should set their CPU recall period at 30B milliseconds (NOS standard) if they have 50 or fewer PNI users; dual-CPU sites should do so with PNI loads of up to 60 users. Sites with larger PNI loads should use a setting of 15B milli- seconds for the CPU recall period. Sites which deviate from this recommendation may estimate their mean PNI echo time, using the fol- lowing approximation: CPU Recall Period 15B 30B 45B 1-CPU 155 197 220 2-CPU 145 185 221 - Sites with less than 150 users which use only CIU page 9 communications should set their CPU recall period to 30B milliseconds (NOS standard) or higher, up to 45B. If a site has more than 150 users, or if a setting greater than 45B milliseconds is desired, it may be necessary to experiment to find the high- est acceptable setting. 4. Systems which are using ESM in ESM mode (as opposed to ECS mode) should add "X.ESM(NK)." as a DSD entry to ensure that this job runs as soon as the operating system is loaded to reload the relocation memory. page 10 3 The PLATO Configuration File The PLATO configuration ("config") file contains software parameters which may be unique on each system. It allows the local site personnel control over resources which have considerable impact on performance. The "config" file is a text record on the deadstart tape. The first line in the "config" file must be the name of the record. The PLATO application checks that the first six characters of the "config" file are the required letters "config". However, multiple "config" files may exist, named "config1", "config2", etc. Comments may be added as lines starting with "*". All lines that are not entirely comments must follow this format: parameter=value. comment where: parameter = a valid keyword described in the following sections value = an appropriate setting for your system comment = any additional comment you wish to make page 11 3.1 Types of Keywords The defined keywords can be divided into several different "types" dependent on what is controlled by that keyword. The following keywords control parameters affecting the PLATO Application as a whole and its interface to the operating system. Application load/drop control nampd Security passw secur syot Identification famly prtun subun Extended memory allocation flx rax Application interface to network nam namto Background PLATO batch jobs njob cshar The following keywords control parameters affecting the PLATO Application as a whole internally. Application availability instl Internal security ptlim pwbot pwnot pwoff sysac page 12 PLATO system identification rid sid Central Processor speed cpspd PLATO disk system resources ncmb ndsus npms Internal extended memory allocation Parameters dependent on memory size cblth cdisk fastl forml lesns nparc Parameters dependent on number of users jbnks niob nn1si nsite n1sit quesz users Internal formatter parameters fofrl Author deletion parameters edel1 edel2 edel3 sysdl EM manager parameters emgr1 emgr2 emgr3 emgr4 PLATO feature availability page 13 cmp confr cstat estat mcond ncond PLATO account parameters nacnt nalog Runner program parameters nrunr Data formats datef timef Background PLATO batch job resources bgecs bgpct PLATO Inter-system Link parameters netms See the "Keyword Definitions" section for an alphabetic list of keywords and their definitions. Keywords for the CIU network and for multi-mainframe systems are described in appendices later in this Handbook. page 14 3.2 Keyword Definitions The description of each configuration file entry includes the following information: keyword: short definition of keyword complete definition of keyword restrictions on the value assigned to this keyword (if any apply) usual values for different configurations default value if this keyword is omitted from the configuration file The value assigned to a keyword may be one of the following. a positive decimal integer a positive octal integer (by specifying "b", i.e., 10b) the string ON the string OFF alphanumeric string of one to three characters alphanumeric string of one to seven characters When a parameter is dependent on memory size, this means the Extended Memory actually assigned to the PLATO application, not the entire physical EM size. The recommended values for all keywords should be considered as guidelines only, particularly those which are dependent on memory size. All values may have to be adjusted for the maximum performance of the system. Extreme care must be taken when changing these values. Setting values far from the recommended or default values may have severe impact on system performance or load capacity. page 15 3.2.1 Keywords: A - B BGECS: background batch job extended memory The value of "bgecs" is the number of 1000b-word blocks of extended memory within the extended memory field length of the application to be reserved for batch jobs (i.e., PLATO print jobs, PF commands, etc.). For systems with ESM, this should be a multiple of 10b or it will be rounded up to the nearest multiple of 10b. For single mainframe systems, a value of 20b is usually sufficient. Default value: 20b BGPCT: excess processing time (background) percentage The value of "bgpct" is used to specify what percentage of excess processing time should be made available to users running with the -backgnd- TUTOR command in effect. The remainder of the processing time, if any, will be made available for batch jobs. The value of "bgpct" must be an integer greater than 0 but less than 100. The greater the value of "bgpct" the more excess processing time is given to users of lessons with -backgnd- commands. On systems with light batch loads, it may be best to give -backgnd- users priority (i.e., set "bgpct" to a high value) to minimize CPU idle time. Default value: 50 3.2.2 Keywords: CA - CO CBLTH: CONDENSOR source buffer length As the CONDENSOR source buffer is made larger, more EM is required for each CONDENSOR, but less disk activity is required since more blocks of the source file can be read into the buffer with a single disk access. The value of "cblth" must be a positive integer less than or equal to 21 and is in units of the TUTOR block length. Default value: 3 for systems with less than 1000K of EM 21 for systems with 1000K or more of EM CDISK: CONDENSOR overlays on disk page 16 If the value of "cdisk" is ON, the main CONDENSOR overlays (PLATO Author Language, each level of the Micro PLATO Language and Central Micro PLATO) are loaded from disk rather than from EM. This will save a large amount of EM, but condense times for Micro PLATO lessons will be greatly increased. If the value of "cdisk" is ON, the value of the "ncond" keyword will be set to 1. The usual value of "cdisk" is: a. ON for systems with less than 1000K of EM b. OFF for systems with 1000K or more of EM Default value: OFF CMP: Central Micro PLATO availability The value of "cmp" determines the availability of the Central Micro PLATO (CMP) Executor. If the value of "cmp" is OFF, the CMP overlay in the CONDENSOR is not loaded into EM, saving memory. If the value of "cdisk" is ON, there will be no savings and this keyword will simply make execution of CMP lessons impossible. The usual value of "cmp" is OFF. Default value: OFF CONFR: TERM-confer (Teleconferencing) availability The value of "confr" determines the availability of the Teleconferencing feature, including TERM-confer and lesson "s0confer". This control is necessary for countries in which this feature would be in violation of laws governing communications. The usual value of "confr" is ON. Default value: ON 3.2.2.1 Keywords: CP - CZ CPSPD: Central Processor speed Setting this keyword to the correct value is necessary to insure that lessons execute the same on all machines, regardless of the actual machine speed. The following figures are rough estimates only. Use lesson "s0cpspd" to get a more accurate estimate. Setting the value of this keyword far from that recommended by this table may have severe impact on system performance or load capacity page 17 and is discouraged by Control Data. If you experience any system problem while the value of the CPSPD keyword is set to a value far from that recommended by this table, before reporting the problem, reset the value to that recommended in the table below. If the problem persists, you may then report it. The value of "cpspd" should be set as follows: Cyber 73 cpspd=1000. Cyber 171 cpspd=620. Cyber 172 cpspd=900. Cyber 173 cpspd=1500. Cyber 174 cpspd=1500. Cyber 175 cpspd=4000. Cyber 720 cpspd=900. Cyber 730 cpspd=1600. Cyber 810 cpspd=1400. Cyber 815 cpspd=1400. Cyber 825 cpspd=1700. Cyber 830 cpspd=1700. Cyber 835 cpspd=1700. Cyber 840 cpspd=3000. Cyber 845 cpspd=3000. Cyber 850 cpspd=4200. Cyber 855 cpspd=4200. Cyber 860 cpspd=5000. Cyber 960-11 cpspd=4800. Cyber 960-31 cpspd=6900. Cyber 990 cpspd=21600. Default value: 1400 CSHAR: CONDENSOR CPU sharing priority If a job of priority "cshar" or greater is in WAIT state (waiting for the CPU) during a condense, the condensor will pause (recall) periodically to let the job get some processing time. Condenses will take longer. The usual value for: PLATO-only systems: 70b. Time-sharing systems: same as the PR parameter for the time-sharing (TS) service class. Default value: 70b. CSTAT: CONDENSOR statistics The value of "cstat" determines the availability of an EM buffer for the collection of CONDENSOR statistics. If a buffer is available, lesson "system1" may be used page 18 to collect and view TUTOR command condensing statistics. The value of "cstat" is usually OFF. Default value: OFF 3.2.3 Keywords: D - E DATEF: date format The value of "datef" controls the format of the data produced by the -cdate- TUTOR command. This command is used in many system lessons to display the current date. The value of "datef" must be one of the integers 1,2 or 3. The format produced by each of these values is: a. datef=1. mm/dd/yy b. datef=2. dd/mm/yy c. datef=3. yy/mm/dd The usual value of "datef" depends on the local site. Default value: 1 EDEL1: EM deletion pass 1 When a student needs EM, and there is not enough available, authors using more than "edel1" words of EM may be backed out of their current lesson. See the section on "Controlling EM deletion" for more information. The usual value of "edel1" is 8000. Default value: 8000 EDEL2: EM deletion pass 2 If not enough EM is obtained after pass 1, a second pass is made, backing out authors using more than "edel2" words of EM. See the section on "Controlling EM deletion" for more information. To be effective, "edel2" must be less than "edel1". The usual value of "edel2" is 5500. Default value: 5500 EDEL3: EM deletion pass 3 page 19 If enough EM is not obtained by the first two passes, a third pass is made backing out authors using more than "edel3" words of EM. No more passes are made, even if pass 3 is not successful. See the section on "Controlling EM deletion" for more information. To be effective, "edel3" must be less than "edel2". The minimum allowable value is 1500. The usual value of "edel3" is 3000. Default value: 3000 EMGR1: maximum short EM request See the section on "EM Manager parameters" for more information. The usual value of "emgr1" is 2000. Default value: 2000 EMGR2: minimum EM free for long request See the section on "EM Manager parameters" for more information. The usual value of "emgr2" is 10000. Default value: 10000 EMGR3: EM available scan threshold See the section on "EM Manager parameters" for more information. Default value: 40000 for systems with less than 1000K of EM 80000 for systems with 1000K or more of EM EMGR4: normal free EM desired See the section on "EM Manager parameters" for more information. Default value: 30000 for systems with less than 1000K of EM 50000 for systems with 1000K or more of EM page 20 ESTAT: execution statistics The value of "estat" determines the availability of an EM buffer for the collection of execution statistics. If a buffer is available, lesson "system1" may be used to collect and view TUTOR command execution statistics. The value of "estat" is usually OFF. Default value: OFF 3.2.4 Keywords: F FAMLY: NOS family name The value of "famly" is the NOS family to be used by the PLATO application load procedures and submitted jobs. Any user-submitted jobs will use this family unless it is overridden by a family name stored in the user's signon record. More information regarding NOS families may be found in the NOS Analysis Handbook. The value of "famly" must be a one to seven character alphanumeric string. If the form "famly=." is used, the default NOS family will be used. Default value: default NOS family FASTL: fast output buffer length The value of "fastl" determines the size of the FRAMAT fast output buffer, which contains output with the highest priority. Very short output strings such as key echoes are kept in this buffer. The system will issue a dayfile message when this buffer is too short so that it may be lengthened. If this buffer length must be increased much beyond the usual range, it may indicate that a terminal is sending in too many keys. Default value: 500 for systems with less than 750K of EM 1000 for systems with 750K to 1500K of EM 2000 for systems with more than 1500K of EM FLX: extended memory field length (FL) The value of "flx" determines the amount of extended memory to be reserved for the PLATO application. The actual EM FL is set to (value of "flx") * 1000b. If the value of "flx" is set to 0, all available contiguous EM beginnning at "rax" will be reserved. If you wish to segment EM between PLATO and other page 21 applications, setting "flx" will limit PLATO to that amount of EM, leaving the rest free. Typical values: ECS-1 ECS-2/ESM/UEM 500K system 1730b 2000b 750K system 2760b 3000b 1000K system 3660b 4000b 1500K system 5610b 6000b 2000K system 7540b 10000b In general, the method to determine "flx" is to subtract "rax" from the extended memory field lengths shown above. For example, if you have 750K of UEM and set "rax" to 30b, then "flx" should be set to 3000b - 30b or 2750b. Default value: 0 FOFRL: formatter-to-framer buffer lengths The value of "fofrl" determines the lengths of two buffers holding formatted terminal output before it is "framed" (packaged for and sent to a particular network driver). One buffer is used for short bursts of output, such as key echoes. The other is for lengthier transmissions. This is the buffer referred to by the "wxcb overflow" dayfile message. Increasing the value of this keyword will reduce the frequency of this problem. Default value: 4000 FORML: slow output buffer length The value of "forml" determines the length of the FRAMAT slow output buffer, which contains output with the lowest priority. Medium to long output strings are kept in this buffer. The system will issue a dayfile message when this buffer is too short so that it may be lengthened. If this buffer length must be increased much beyond the usual range, it may indicate that a terminal is sending in too many keys. Default value: 960 for systems with less than 750K of EM 1920 for systems with 750K to 1500K of EM 2400 for systems with 1500K or more of EM 3.2.5 Keywords: G - M INSTL: installation mode The value of "instl" determines the operating mode of the PLATO application, either installation mode or page 22 normal mode. Under installation mode, only certain system groups are allowed to sign in. The value of "instl" must be either 0 for normal operation or 1 for installation mode. The usual value of "instl" is 0. During PLATO application installation, it is set to 1 whenever the PLATO application is loaded via the "PLAUPD." or "PLAINS." DSD-commands. Default value: 0 JBNKS: auto-break judge buffers The value of "jbnks" determines the number of buffers to be defined for the system to store information used for judging student responses when the user must auto- break at the end of a time-slice. The value of "jbnks" must be a postive integer exactly zero or greater than 4 but less than or equal to 48. The usual value of "jbnks" is determined by the number of users of the PLATO application. There should be one buffer defined for every 16 users signed on at once. If the value of "jbnks" is set to 0, the system will change it to: (value of "users")/16 + 4. Default value: 0 LESNS: lesson buffer entries The value of "lesns" determines the number of entries which can be made in the EM lesson buffer. These entries are the executable binaries of lessons, storage, commons and other subfiles, router variables, local variables, student banks, etc. Default value: 500 for systems with less than 750K of EM 1000 for systems with 750K to 1500K of EM 2000 for systems with more than 1500K of EM MCOND: minimum number of CONDENSORs The value of "mcond" determines the minimum number of CONDENSORs which will be left at control points when the condense queue is lower than the minimum at which the PLATO application will load additional CONDENSORs. This is most useful in multi-mainframe systems and systems which are dedicated to running PLATO with a large number of courseware authors where there is a demand for faster response to condense requests. page 23 This keyword has no effect if "ncond" is set to 1. The usual value for "mcond" is 1. Default value: 1 3.2.6 Keywords: NA - NB NACNT: highest PLATO account number The value of "nacnt" determines the largest integer which may be assigned as an account number to any PLATO account in your system. Note that this is NOT the same as the number of accounts existing on the system since there may be account numbers which are not currently assigned to an account. However, "nacnt" does determine the maximum number of accounts which may be created. The value of "nacnt" must be less than or equal to 500. There is no usual value for "nacnt" since it depends on the policies of the local site. Default value: 200 NALOG: number of account file management logs The value of "nalog" determines the number of account file management logs ("acclog0", "acclog1", etc.), on the system. Contact PLATO Support before changing this value. The usual value of "nalog" is 4. Default value: 4 NAM: PLATO-NAM Interface (PNI) availability The value of "nam" is set to the number of copies of NAM and PNI running on a system when the ASCII network is in use for PLATO. On single mainframe systems, the value of "nam" can be the integers 0 or 1. On systems which use the ASCII network for PLATO, the value of "nam" must be 1. Default value: 1 NAMPD: PLATO drop time The value of "nampd" is the time in seconds between page 24 the time the last user of PLATO through the ASCII network signs out and the time PNI drops the PLATO application. This can be used to release the CM in use by the PLATO application when it is not being used. If the value of "nampd" is set to 0, PNI will never drop PLATO. If the site wishes PLATO to load and drop as users sign on and off, a non-zero value should be used. Normally, it takes the PLATO application two minutes to initialize, so a site should not specify this value such that the application drops too soon. A suggested value might be 2 minutes (120 seconds), but it is highly dependent on the user sign-on activity at the site. This keyword should never be used on systems which use both the ASCII and CIU networks. Default value: 0 NAMTO: PNI log-out timeout The value of "namto" determines the length of time between the time a user presses SHIFT-STOP to return to the "Press NEXT to Begin" display and the time the user is logged out of NAM. PNI checks for this timeout only once every 30 seconds, so any number specified may actually have a range of plus or minus 30 seconds. If the value of "namto" is set to 0, PNI will immediately log out a user when SHIFT-STOP is pressed to return to the "Press NEXT to Begin" display. There is no usual value for "namto" since it depends on the policies of the local site. Default value: 120 3.2.6.1 Keywords: NC - NM NCMB: number of PMS CM buffers The value of "ncmb" determines the number of CM paths for disk-to-EM transfers when the PMS low-speed port/DDP is busy or not defined in the NOS EQPDECK. The value of "ncmb" must be an integer greater than or equal to 0 but less than or equal to "npms". Systems on 800-series mainframes must set this value to 0 or use the default value. Systems on 700-series mainframes with a "D1" equipment defined in the EQPDECK should set "ncmb" to "npms"-1. page 25 Systems on 700-series mainframes with no "D1" equipment defined in the EQPDECK should set "ncmb" equal to "npms". See the section on "Settng up your disk system" for more information. Default value: 0 NCOND: number of CONDENSORs The value of "ncond" determines the maximum number of CONDENSORs which are allowed to run. If more than one CONDENSOR is allowed, additional ones will be started automatically when the condense queue builds up. The additional CONDENSORs will be dropped when the condense queue goes below the threshold where additional CONDENSORs are loaded unless the "mcond" keyword is used to allow the additional CONDENSORs to remain running. The value of "ncond" must be an integer greater than 0 but less than or equal to 3. This keyword has no effect if the value of "cdisk" is ON. In this case, the system will support only one CONDENSOR. The usual value of "ncond" is 1. Default value: 1 NDSUS: maximum number of master files The value of "ndsus" determines the maximum number of PLATO master files which may be attached at one time. The value of "ndsus" must be a positive integer less than 116. There is no usual value for "ndsus" since it is dependent on the amount of disk space desired for the local site. Default value: 12 NETMS: network system table size The value of "netms" determines the length of the network system table contained in common "link" of file "sysfile". This common must be at least (1 + 10 * "netms") words long. See the "Network Management" section for more information before changing the value of this keyword. The value of "netms" should be set to the number of systems in the network for which an "authors" database or a PLATO inter-system link exists. page 26 There is no usual value for "netms" since it is dependent on the local site's network configuration. Default value: 10 NIOB: number of subfile I/O buffers The value of "niob" determines the number of "subfile I/O buffers" which are used when reading commons, charsets, linesets, microtables, access lists, dataset records, nameset records or TUTOR file blocks from disk. The usual value of "niob" is: a. 4 for systems with less than 64 users b. 8 for systems with 64 - 127 users c. 12 for systems with 128 - 255 users d. 16 for systems with more than 255 users When the value of "niob" is set to zero, the system will automatically set it to the usual values given above. Default value: 0 NJOB: number of PLATO batch jobs The value of "njob" determines the maximum number of jobs submitted through PLATO which can be running at the same time. This includes the PLATO system control points. The usual value of "njob" is 64. Default value: 64 3.2.6.2 Keywords: NN - NR NN1SI: number of NAM (PNI) sites The value of "nn1si" determines the number of PLATO sites (groups of 32 terminals) for use with the ASCII network. The value of "nn1si" must be an integer greater than or equal to 0 but less than or equal to "nsite". There is no usual value for "nn1si" since it is dependent on the number of users on the system at the same time. Default value: 2 NPARC: number of output parcels The value of "nparc" determines the number of buffers of formatted output which are waiting to be sent to the network. page 27 Default value: 500 for systems with less than 750K of EM 750 for systems with 750K - 1500K of EM 1000 for systems with more than 1500K of EM NPMS: number of copies of PMS The value of "npms" determines the number of copies of the PLATO disk driver PP, PMS, to be run. Using more than one copy of PMS will improve disk performance, but keep in mind that each additional copy requires another dedicated PP while the application is active. The number of disk channels available and the disk drive configuration on the available channels will also affect the number of PPs which will optimize performance. See the section on "Setting up your disk system" for more information. The value of "npms" must be 1, 2, or 4. The usual value for "npms" is 1. Default value: 1 NRUNR: number of runner stations The value of "nrunr" determines the maximum number of runner programs which may be running at the same time. See the PLATO Operations Guide for more information on runner programs. The value of "nrunr" must be at least 3 greater than the number of runners which must be active continuously throughout the day. Each additional runner station will cost about 500 words of EM. Changing this value will affect the station numbers which runner stations occupy and could affect the logical site assignments of these and other stations. See the PLATO Operations Guide and the "EM management" section of this Handbook for more information on logical sites. The usual value of "nrunr" is 10, but the local site may add more runner stations at their option. Default value: 10 3.2.6.3 Keywords: NS - NZ NSITE: number of physical sites The value of "nsite" determines the total number of PLATO sites (groups of 32 terminals) in the network. The value of "nsite" should be one greater than the total number of sites which will be used by real users since page 28 runner programs occupy the highest site. On most systems, where the ASCII (PNI) network is the only communications network in use, "nsite" should be set to one greater than "nn1si". There is no usual value for "nsite" since it is dependent on the number of users on the system at the same time. Default value: 3 N1SIT: first NAM (PNI) site The value of "n1sit" determines the number of the first PLATO site (group of 32 terminals) assigned to the ASCII network. On most systems, where the ASCII (PNI) network is the only communications network in use, "n1sit" should be set to 0. Default value: 0 3.2.7 Keywords: O - Q PASSW: password required for system lessons The value of "passw" determines if NOS user name passwords are to be required in jobs submitted by system lessons. If the value of "passw" is OFF, system lessons may use the -submitm- and -submitx- commands without specifying a password for the NOS user name to be used. Default value: OFF PRTUN: NOS user number for print jobs The value of "prtun" specifies the NOS user number to be used when submitting central system print requests through lesson "prints". The value of "prtun" must be a one- to seven-character alphanumeric string which is a legal NOS user name. The user index for this user name must be less than 377770b. The usual value of "prtun" is "prints". Default value: "prints" PTLIM: password time limit The value of "ptlim" determines the number of days page 29 until a user is prompted to change their PLATO signon password when they attempt to sign on. There is no usual value for "ptlim" since it is dependent on local site policies. Default value: 60 PWBOT: attempts at password before booting The value of "pwbot" determines how many consecutive unsuccessful attempts at a PLATO signon password will be allowed before the user is required to re-enter the signon name and group. All attempts after this limit is reached returns the user to the "Press NEXT to begin" display. Default value: 5 PWNOT: attempts at password before note The value of "pwnot" determines when and how often a "security breech" note will be written to file "s0sysmsg". Every attempt that is an even multiple of "pwnot" will generate a note. Default value: 25 PWOFF: attempts at password before signon turned off The value of "pwoff" is the number of consecutive unsuccessful attempts at a PLATO signon password before the signon is turned off for security reasons. The default value has been chosen as low enough to prevent guessing a user's password, but high enough to prevent someone from turning off a user's record by deliberately guessing the user's password incorrectly. Default value: 1000 QUESZ: backgnd, auto-break queue size The value of "quesz" determines the length of various queues used by the PLATO executor, such as the queue of users waiting for -backgnd- execution time or of users waiting for another time-slice. The value of "quesz" must be an integral power of 2. The usual value of "quesz" is: a. 64 for systems with less than 64 users b. 128 for systems with 64 - 127 users page 30 c. 256 for systems with 128 - 255 users d. 512 for systems with more than 255 users When the value of "quesz" is set to zero, the system will automatically set it to the usual values given above. Default value: 0 3.2.8 Keywords: R RAX: extended memory reference address (RA) The value of "rax" determines the PLATO application extended memory reference address. The actual EM RA is set to (value of "rax") * 1000b. If the value of "rax" is set to 0, the value of "rax" used will be automatically determined by the system. If a value is specified, MASTOR will first request the "track" on the NOS EM device which contains that address. If that track is not available, it will attempt higher- numbered tracks until it finds enough contiguous tracks to satisfy the requested amount ("flx"). The actual RAX/FLX values are also a factor of extended memory type & size. NOS allocates EM as a file, which MASTOR uses as directly addressable memory. Differences in units of allocation force some rounding to be done. For this reason, the actual numbers may not be exactly what was requested. Default value: 0 RID: routing identifier The value of "rid" specifies a system identifier which is used by features such as lesson "authors" and the PLATO inter-system link. The value of "rid" is a three-character alphanumeric string established for each system by Control Data at installation time. You must use this pre-determined value and must not change it once it has been set. The value of "rid" must be unique across all PLATO systems. Changing the value of "rid" after installation can cause features to work incorrectly. Default value: 0 3.2.9 Keywords: S SECUR: application security level The value of "secur" determines the availability of features which can be used to inspect central memory page 31 and extended memory of running jobs. The value of "secur" is either ON or OFF depending on the desired security level. When the value of "secur" is ON, system lessons are prevented from accessing NOS information. For example, no console displays may be seen via lesson "console". The usual value of "secur" is OFF. Default value: OFF SID: system identifier The value of "sid" specifies the name of the PLATO system for display purposes. It is used in features such as the "zsystem" reserved word, lesson "authors", the signon display and the PLATO inter-system link. The value of "sid" must be a one- to seven-character alphanumeric string. Default value: "cdc" SUBUN: submit user name The value of "subun" specifies the NOS user name to be used to submit the PLATO load procedures. The value of "subun" must be a one- to seven-character alphanumeric string which is a legal NOS user name. The submit file PLATOD must be in the permanent file catalog of this user name. The user index for this user name must be less than 377770b. The usual value of "subun" is "sys". Default value: "sys" SYOT: system origin permission The value of "syot" determines who can submit system origin jobs from a PLATO application terminal. The value of "syot" must be one of the following. 0 = No system origin jobs may be submitted except jobs used to load PLATO control points. 1 = System origin jobs may be submitted by any system lesson. 2 = System origin jobs may be submitted by any system lesson or any user validated for it page 32 (CSOJ bit set in NOS validation file for the user name to be used for the submit). The value of "syot" must be greater than 0 on single mainframe systems so that utilities such as "ldr" will work correctly. SYSAC: system user access The value of "sysac" determines if remote system-level users are allowed access to the PLATO system. The value of "sysac" is either ON or OFF, depending on whether groups "s" and "coserv" will be allowed to sign on to the system. These groups are owned by Control Data and are used to perform system software and course- ware maintenance. The usual value of "sysac" is ON. SYSDL: system lesson deletion The value of "sysdl" determines if the system may back authors out of specific system lessons to obtain memory for students. The value of "sysdl" is ON if the system is allowed to back authors out of system lessons. Author deletion must also be enabled in lesson "site". It is recommended that this keyword be used only on systems which have a high student usage and very little development work by authors. Use of this feature can cause work being done by authors to be lost when they are backed out. See the section on "Controlling EM deletion" for more information. The usual value of "sysdl" is OFF. Default value: OFF 3.2.10 Keywords: T - Z TIMEF: time format The value of "timef" controls the format of the data produced by the -ctime- TUTOR command. This command is used in many system lessons to display the current time. The value of "timef" must be one of the integers 12 or 24. The format produced by each of these values is: a. timef=12. display time in 12 hour format b. timef=24. display time in 24 hour format page 33 The usual value of "timef" depends on the local site. Default value: 12 USERS: maximum number of users The value of "users" determines the maximum number of users who may be signed on at the same time. If the value of "users" is set to 0, the system will change this to 32 * (value of "nsite"). Sites may want to reduce this number to save memory since not all terminals will be signed in at the same time. There is no usual value for "users" since it is dependent on local system needs. Default value: 0 page 34 4 System Lesson Parameters Most system lesson configuration parameters are controlled via lesson "ipedit". The following is a list of parameters which may be changed through options in this lesson. Prime-Time table This table defines the value of the "ptime" reserved word. It is intended to show the hours when the system is fully operational as scheduled. Services-available time table This table determines when the system is fully staffed and operators and consultants are available. Outside of these hours, a message will appear on the signon display stating that services personnel are unavailable. Time zone This option allows changing the time zone identifier which appears along with the current time in several system displays. Archive recycle period This option is used to change the length of time an archive file may exist. "Welcome to PLATO" message This option allows changing a message line on the signon display. PNET "Lock Out" message The option is used to edit the message a user sees when not allowed to sign on if the terminal he is using is not defined in the network database. This will only appear if the "pnet" configuration file keyword has the value ON. Required Master Files table This option allows editing the list of master files which should always be attached when the PLATO application is running. If one or of these master files is missing, users will be prevented from creating new files. Operator's station This option allows setting the station number to which TERM-operator requests are first directed if an operator is signed in at this station. If there is no operator signed in at this station, the request will be directed to operators at other stations. Special station list This option allows editing the list of stations where special system functions can be performed by consultants and system software maintenance groups. The major feature allowed is the ability to inspect files when the password is not known. page 35 Restrict system personnel access This option allows changing the value of the "sysac" configuration file keyword while PLATO is running to temporarily allow system groups to sign on. Edit/inspect system lesson access lists This option jumps to lesson "s0calutil" to allow editing access lists to control user access to restricted system features. Batch submission control This option is used to control who may submit batch jobs and to edit a list of mainframes which can be used. Continuous polling This option allows changing the recall characteristics of the PLATO application which can result in more CPU time being available for batch jobs. This option has a HELP sequence which explains this control. Network management This option is the network system table editor. It is used to edit the list of systems and their characteristics. 4.1 Preferred language table This option allows setting the language some system displays such as the signon display and the Author Mode display will use. The only choices are English and French for these displays, but the "zlang" reserved word is available to user lessons to determine what language is desired. Update level for new files This option is an editor for the list of possible PLATO file types and their "update levels". New files which are created will have their update levels set to the value which appears in this table for the specific file type. When one of these values changes, you will be instructed to change the update level value during the upgrade installation. See the section on "File Conversions" in the PLATO Operations Guide for more information. Multi-CONDENSOR submission This option is used to determine which mainframes in a multi-mainframe configuration CONDENSORs will be submitted to when additional ones are required. Change length of terminal location list This option is used to lengthen the terminal location list which can be viewed in lesson "system1" when new logical sites are added to the system. Change length of EM allocation tables This option can be used to lengthen the EM allocation page 36 tables when new sites are added to the system. page 37 5 EM Management This section describes the management of the EM which has been allocated to the PLATO application. This information concerns memory usage within the PLATO system itself, not how it affects the operating system. 5.1 The Lesson Buffer Depending on the system configuration, a set amount of EM is reserved for overhead. This overhead represents the "binaries" for the various overlays as well as the many tables and buffers used by the application. Some of the overhead is of fixed size, but other parts of it will vary considerably in size, depending on the configuration of the system (i.e., number of sites, master files, etc). What remains, after subtracting the overhead from the EM size, is the lesson buffer. The lesson buffer will contain all lessons, commons, storage, etc., which are in use. Once an entity is no longer in use, the "ECS manager" will periodically be activated and remove that entity from EM to make room for something else. If a user tries to use more EM when there is no more available, problems will arise. It is for this reason that EM must be allocated in an attempt to control the number of such problems, and to whom these problems will occur. 5.2 Logical Sites A "logical site" is a collection of terminals which may or may not be located together. They are related in two ways: (1) use of the terminals is controlled by the application in accordance with a set of rules for that logical site. (2) all of the users of that logical site share (compete) for) the computer memory (EM) allocated for the exclusive use of that site. Logical sites are created and EM is allocated through lesson "allocate". 5.3 Allocateable EM Not all of the lesson buffer may be allocated to the users. Some of it is reserved to contain student banks for each terminal signed in as well as for some of the system lessons. Most system lessons are in EM only when someone is using them (just as any normal lesson). However, a few of them (lessons "edit" and "sysopts", for example) always remain in EM regardless of whether or not someone is actually using them. Thus, you should not allocate EM represented by this lesson buffer overhead. page 38 Furthermore, when users in other system lessons are not charged for the full length of the lesson, a certain amount of the buffer must be reserved for this uncharged EM. The result of all this is when allocating EM, the entire EM buffer must not be allocated to the logical sites. A guideline which has worked well for most systems is to leave about 20% of the lesson buffer unallocated. 5.3.1 How Much to Allocate There is no answer for how much EM can be safely allocated without causing problems for a fixed number of users. Here are two methods to give an estimate as to how much to allocate. Start the allocation with this amount and adjust to conform to actual need. 1. Use lesson "s0config" to determine the size of the lesson buffer for your configuration and do not allocate 20% of the length given. 2. In the "EM management statistics" option in lesson "system1", there is an option entitled "Lesson length/ type distribution" which provides the following: a. the size of the lesson buffer b. the distribution of files by type throughout the lesson buffer c. the amount of lesson buffer overhead d. an estimate as to how much of the lesson buffer may be allocated In order for the estimate to be valid, run the option when the application is running at a peak load. 5.3.2 Adjusting the Allocations Once EM has been allocated, there are several statistics which may be used to determine how well the allocation scheme is working, and adjustments should be made accordingly. a. In lesson "stats", option b, you can see the EM free at 15 minute intervals during the day. If the EM free approaches zero, you are out of EM. This means the total amount of EM is about right; no more should be allocated. b. In the "EM management statistics" section of lesson "system1", you can see the number of times users were totally unable to obtain requested EM. If this number is non-zero, there are times when the entire lesson buf- fer was full and someone tried to get additional EM. In such a case, the user would get a message such as "No EM available". A few of these each day is no problem, but if the number gets too big, the entire system will be affected. In such a case, you MUST lower the EM page 39 allocated to one or more logical sites via lesson "allocate". c. If you or other users receive messages like "You have exceeded your EM allocation", this means your site does not have enough EM allocated for all of its desired uses. You may allocate more to this site if other statistics have indicated that more EM may be available. d. When a site is using all of its allocated EM and a student tries to get more, an author may be deleted to make room for the student, if this option is turned on in lesson "site". These deletions are recorded and may be seen in a PLATO Availability Report (RAFPDD). You may decrease the number of deletions by increasing the EM allocated to the site. However, if no more EM is available to allocate, you may have to accept these deletions. 5.3.3 Actions to Correct Memory Shortages If statistics or messages indicate that there are problems, action should be taken, if possible. a. Reduction of EM allocated to sites should only be necessary if there are several times when users are totally unable to obtain requested EM. In such a case, reduce the total amount of allocated EM. b. Allocate more EM to the logical sites if there are problems and statistics indicate more EM is available. c. If more than one non-system logical site exists, it may be possible to move EM from one site to another. d. Change the system configuration file to reduce overhead. e. Make sure that only essential runners are running during the peak hours of the day. f. Use lesson "enforcer" to disable certain lessons during peak times of the day. Be warned, however, that the enforcer requires EM and may add to the shortage. g. If management prefers to protect one group of users at the expense of another, set up a separate site for each group. Allocate more EM to the "protected" group than to the "unprotected" group. h. Watch for users designing extremely large lessons and try to help them to make them smaller. Encourage authors working on lessons to condense only those blocks they are currently working on. i. Obtaining more EM may be the only alternative. page 40 5.3.4 Controlling EM Deletions This section describes the algorithm used to back authors out of lessons when a student requests memory and there is not enough available in the student's logical site memory allocation. It also shows how to use the "edel1", "edel2", "edel3" and "sysdl" configuration file keywords to change the parameters of this algorithm. if author deletion not allowed for this logical site through option in lesson "site", then exit (failure). set BASE_AUTHOR_EM = 1500. set EM_NEEDED = REQUEST + 5000. set EM_OBTAINED = 0. loop if first pass, then set LIMIT = "edel1", else if second pass, then set LIMIT = "edel2", else if third pass, then set LIMIT = "edel3", else exit (failure). loop get next author to check. set EM_IN_USE = length of (lesson + common + storage). if EM_IN_USE less than LIMIT, then reloop. set EM_AVAILABLE = EM_IN_USE - BASE_AUTHOR_EM. if protected system lesson, then if always protected, then reloop, else if "sysdl" equals OFF, then reloop. if lesson also in use by students at site, then reloop. if lesson in use by more than 3 users, then reloop. back out author. issue NOS account file message (PD entry). set EM_OBTAINED = EM_OBTAINED + EM_AVAILABLE. if EM_OBTAINED greater than or equal to EM_NEEDED, then exit (successful). endloop endloop 5.4 EM Manager Parameters This section describes the usage of the "emgr1", "emgr2", "emgr3" and "emgr4" configuration file entries and how changing these values will affect the PLATO system. Extreme care must be taken if you decide to change these parameters since drastic changes can severly affect the performance of the PLATO application and any other jobs running in the system. The "EM Manager" is a program called periodically by the PLATO system to maintain free space in the lesson buffer. It does this in three phases: 1. by maintaining two different pointers to areas of page 41 free space in the lesson buffer (Search Phase). 2. by deleting unused entries in the lesson buffer (Deletion Phase). 3. by relocating entries in the lesson buffer to open up larger areas of free space (Compaction Phase). The amount of EM sought by the EM manager is set to "emgr4" unless a user request for EM has been refused because of inadequate memory. In this case, the amount sought is set to the greater of 100,000 words or one-eighth of the lesson buffer size. The number 100,000 is the maximum amount of memory which may be requested by a user. Setting "emgr4" lower than recommended values will cause the EM Manager to spend most of its time in the Search Phase and to not advance to the other phases because it will be more likely to find a free space of the amount sought. This will make it use less CPU time, but unused lessons will not be deleted as often and compaction of the lesson buffer will be rare. This will cause users to get more errors due to EM shortages. Setting "emgr4" higher than recommended values will cause the EM Manager to advance to the other phases more often and it will use more CPU time, reducing CPU time which could be given to users and to batch jobs. When the EM Manager is using too much CPU time, users in lessons with -backgnd- commands will freeze up because the EM Manager has priority over -backgnd- users, and condenses will take much longer because the PLATO executor is using most of the available CPU time. 5.4.1 Search Phase If the number of lesson buffer entries is near the maximum, the EM Manager immediately advances to the Deletion Phase. This maximum is the value of the "lesns" configuration file keyword. If there is more free EM available than that specified by the "emgr3" keyword, the EM Manager will immediately exit. Setting "emgr3" lower than recommended values will cause the EM Manager to search the lesson buffer less often and will lead to user errors due to memory shortages. Setting "emgr3" higher than recommended values will cause the EM Manager to search the lesson buffer more often, using up CPU time which could be given to PLATO users and batch jobs. The Search Phase searches the lesson buffer for adequate free EM and sets two pointers called the "short request pointer" and the "long request pointer". The short request pointer is used when filling requests for memory which are shorter than "emgr1". It points to the last page 42 free area of EM smaller than "emgr4" but greater than "emgr1" found during the lesson buffer search. Setting "emgr1" lower than recommended values will cause more user memory requests to be considered as long requests, which take more time to process and will cause the EM Manager to be called more often. This will also make the short request pointer less useful because the area of free EM it points to will be smaller and it is more likely that a user request will occupy the entire free area, leaving none for the next user short memory request. When this happens, the next user must do a full search of the lesson buffer for a free area, which is very expensive in CPU time. Setting "emgr1" higher than recommended values will cause the EM Manager to ignore areas of free memory which would otherwise qualify to be pointed to by the short request pointer. This will lead to many small areas of free EM appearing throughout the lesson buffer which cannot be used until they are collected by the Compaction Phase. The long request pointer is used when filling requests for memory which are greater than "emgr1". It points to the first area of EM larger than the amount sought during the lesson buffer search. If no area of free EM is found which is larger than the amount sought, the EM Manager advances to the Deletion Phase. 5.4.2 Delete Phase The Deletion Phase searches the lesson buffer for a pre- determined amount of time, deleting unused entries. It begins the search at the point where it left off the last time is was called. If the EM Manager must exit before it has finished a complete search of the lesson buffer due to running out of time, it saves the point it reached and sets a flag so it will begin with the Compaction Phase when it is called again. If the search reaches the end of the lesson buffer before the time limit has been reached, the EM Manager will reset the short request pointer and the long request pointer. If an area of free EM larger than the amount sought could not be found and if there is at least 20,000 words of free EM over- all which could be used if it were in one large area, the EM Manager will advance to the Compaction Phase. Otherwise, it exits. 5.4.3 Compaction Phase If there less than twice the value of "emgr2" words of EM available throughout the lesson buffer, the EM Manager will return to the Deletion Phase to attempt to delete more lessons. This is done because the Compaction Phase is extremely expensive in CPU time and this amount is too small to be worth the effort it would take to compact it. The value of "emgr2" is also page 43 used to reject user requests for large amounts of EM when there is less than "emgr2" words free. Setting "emgr2" lower than recommended values will allow users making requests for large amounts of EM to use up EM which should be reserved for the shorter requests. Priority should normally be given to users requesting small amounts of memory. Setting "emgr2" higher than recommended values will cause user requests for large amounts of EM to be rejected more often, which leads to the EM Manager searching for larger amounts of free EM more often. Since it must advance to the higher Phases in order to obtain the larger amounts of free EM sought, it will consume more CPU time. If there is enough memory available to make the Compaction Phase worth the CPU time it will take, the EM Manager searches the lesson buffer for entries which can be moved to open up larger free areas of EM. When it completes this search, it resets a flag so the EM Manager will return to the Search Phase when it is called again. page 44 6 Disk System Management 6.1 Setting Up Your Disk System Optimization of the PLATO disk system is done by proper use of the following. 1. Sharing use of mass storage devices between PLATO master files and NOS. Each copy of the PLATO disk driver (PMS) can process disk requests on several different mass storage devices. The processing of a disk request consists of two distinct steps, physically moving the read/write head on the device to the proper position and transferring the data from the disk to PLATOs extended memory. Each copy of PMS can direct the positioning of the read-write head on several different mass storage devices at the same time, but can transfer data from only one mass storage device at a time. The positioning process is much more time-consuming so it is best to avoid sharing the use of a mass storage device between NOS and PLATO files since this could result in conflicts between different PPUs wishing to position the device at the same time. PMS avoids deadlock conflicts by dedicating itself to positioning a device which is shared by the NOS system instead of attempting to position other devices at the same time it is positioning a shared device. This will slow down processing of all following disk requests. PMS dedicates itself to positioning a device when it has any of the following characteristics. equipment not of type DD, DG, DI, DJ, DK, DL, DM, DQ copy of system on device device shared between mainframes dayfile, errorlog, accountlog or mainlog on device files other than master files attached to jobs temporary, rollout or output files allowed on device multi-spindle device independent-shared device 2. Assigning Equipment Status Table (EST) entries for mass storage devices which contain PLATO master files. This factor is not important for systems using only one copy of the PLATO disk driver. When two copies are used, one PPU processes all requests for devices with even numbered EST entries and the other processes all requests for devices with odd numbered EST entries. When four copies are used, the distribution of PPUs to devices is: PPU Last Digit of EST ordinal 0 0,4 page 45 1 1,5 2 2,6 3 3,7 3. Creating PLATO master files with the MFCREAT utility. Master files should be created individually so that the tracks allocated to the file will be contiguous. This will reduce the amount of work required in the disk system to find the proper track for a disk access. If more than one job is creating a master file at the same time, the tracks allocated to each file will be randomly inter- mixed. This also applies to copying master files from one disk or tape to another by using NOS utilities. 6.1.1 Setting Up Your Disk (continued) 4. Setting the "npms" PLATO configuration file entry. This parameter determines the number of copies of the PLATO disk driver (PMS) to be loaded when the MASTOR job is initialized. This disk driver transfers data between the PLATO master files and PLATO's extended memory (EM) where it is accessed by users. The number of copies of PMS must be a power of 2 (i.e., 1, 2, or 4). Each copy of PMS used occupies a dedicated PPU. PMS uses a disk channel when processing a disk request and, on 700-series mainframes only, uses a distributive-data path (DDP) port access to ECS or a low-speed port access to ESM or a CM-data-transfer path, which is defined by the "ncmb" configuration file entry. PMS uses the EM port defined by the "D1" EQPDECK entry. This equipment is shared with other PPU programs, such as MRQ and MAS. On 800-series mainframes, PMS uses direct access to UEM to transfer data and does not need a CM-data-transfer path. The number of copies of PMS to be used depends on the following factors. 1. Maximum number of users active on the system at one time. 2. Number of disk controllers and disk channels configured for the system. 3. Number of DDPs, ESM low-speed ports or CM-data- transfer paths configured for the system. 5. Setting the "ncmb" PLATO configuration file entry. This configuration file entry determines the number of CM-data-transfer paths available for use by PMS when a DDP access to ECS or a low-speed port access to ESM is not available (either none are defined for the system, or all are reserved by other PPs). Users of 800-series machines must set this parameter to zero or omit it from the config- uration file. For 700-series machines, this parameter page 46 should never be set higher than the "npms" configuration file entry since this would just waste CM and not improve performance. A general guideline to follow is that "ncmb" should be set to "npms" minus the number of DDP or low- speed ports available for use by PMS. In practice, if CM is short on a lightly-loaded system, this parameter may be set lower since the copies of PMS are very unlikely to all need a CM data transfer path at the same time. 6.2 User File Space Management 6.2.1 File Space Monitoring File space should be monitored on a regular basis. The amount of space in use and that still available may be seen by looking at the options in lesson "operator". While looking at "operator", there are 3 things that should be looked for: 1. If another master file is necessary, because the current ones are almost used up. 2. If another master file slot needs to be added. For a smooth production environment, there must always be one slot for each required master file, plus one additional master file slot for special operations (e.g., loading a backup master file to get a backup copy of a lesson). To add another slot, simply change the value of the "ndsus" keyword in the configuration file. 3. If another disk unit is necessary. The initiative for obtaining an additional disk unit should be started well in advance of its actual need. When you start to use the last unit, it is time to think about getting the next unit. 6.2.2 Adding a Required Master File The following steps must be followed whenever a new required master file is added. a. Change EQPDECKs if a new disk is to be added. b. Create the master file with MFCREAT. c. Change procedure MFNX on the deadstart tape. Both the RESOURC and ATTACH commands may have to be changed. d. You may need to increase the value of the "ndsus" keyword in your PLATO configuration file. e. Make changes to dump and load procedures so that the new master file will be properly dumped. This includes changing MFDX and the master files to be page 47 dumped table through BACKMOD. f. Build a new deadstart file with the modified copies of the EQPDECKs, MFNX, MFDX and your configuration file. g. Reload the operating system on the new deadstart file. h. Reload the PLATO application. The new master file should be attached by MFNX during initialization. i. Change the required master files table through lesson "ipedit". Refer to the PLATO Operations Guide for more information. 6.2.3 Changing a Required Master File The following steps must be followed whenever an existing master file is changed, such as when changing the NOS name of a master file or changing the disk pack on which a master file is located. This procedure is also using during the initial installation of published courseware. a. Change EQPDECKs if a new disk is to be added. b. Make the required master file name change or move the master file to its new location. c. Change procedure MFNX on the deadstart tape. Both the RESOURC and ATTACH commands may have to be changed. d. You may need to increase the value of the "ndsus" keyword in your PLATO configuration file when doing the initial installation of courseware. e. Make changes to dump and load procedures so that the new master file will be properly dumped. This includes changing MFDX and the master files to be dumped table through BACKMOD. f. Build a new deadstart file with the modified copies of the EQPDECKs, MFNX, MFDX and your configuration file. g. Reload the operating system on the new deadstart file. h. Reload the PLATO application. The changed master file should be attached by MFNX during initialization. i. Change the required master files table through lesson "ipedit". Refer to the PLATO Operations Guide for more information. 6.3 Binary File Space Management page 48 Lesson "binary" is a runner job which periodically goes through all of the binary master files and purges old binaries (thus making room for new ones). The criteria for deletion may be changed by systems personnel by executing the lesson itself. The controlling parameters are: a. Minimum age for deletion: This is the minimum number of hours a binary must exist before it is normally a candidate for deletion. This is normally set to 24. b. Disk space low threshold: Binary deletion will be initiated whenever the number of file parts remaining on the master file is less than this number. This is normally set to 500. c. Disk space high threshold: Once binary deletion has begun on a master file, it will continue until either this number of file parts are free or until the entire master file has been scanned. This is normally set to 900. d. Number files threshold: Binary deletion will be initiated whenever the number of files on a master file is greater than this number. page 49 7 CPU Usage Management 7.1 Statistics Collection CPU usage may be examined via the "CPU consumption" option in lesson "system1". If you wish to collect statistics over a long period of time, you should do the following: a. Create file "s0cpudata". NOTE: Since this file name is longer than 8 characters, use the "create a file" option under the "File Options" in lesson "operator" to create it. b. Add "s0cpustat" as a runner. These statistics may also be viewed via the option in "system1". 7.2 Adjusting "cpspd" Application lessons should work the same on all systems, regardless of the machine speed. In order to do this, the PLATO application must give more CPU time to users on slow machines and less to users on fast machines. This is done by setting the "cpspd" configuration file keyword to the correct value for your machine. Initially, "cpspd" should be set to the value given in the section on configuration file keyword definitions. Lesson "s0cpspd" may then be executed to adjust the value of "cpspd" for the specific machine configuration in use. 7.3 Adjusting "cshar" The "cshar" parameter is provided to allow sites to moderate the effect of the PLATO condensor with respect to other NOS jobs. The PLATO condensor runs at CPU priority 72, in the range restricted to subsystems. Time-sharing and batch jobs usually run at CPU priorities of 30-50. When the PLATO condensor is active, jobs at lower priorities are effectively blocked. This is particularly annoying to time-sharing users, who are waiting for the initial feedback from their command. The delay may be up to several minutes long for each lesson being condensed. The "cshar" parameter specifies the priority at which the condensor begins to share the CPU. When a job of priority "cshar" or greater is in WAIT state (waiting for the CPU), the condensor will pause (via RECALL) periodically to let other jobs get some processing time. However, this will page 50 cause longer condense times. The advantage to this method, rather than specifying a lower CPU priority for the condensor, is that the effect on con- dense times is fairly constant, regardless of the number of competing jobs. On PLATO systems with time-sharing users, we suggest that "cshar" be set to the same value as the PR parameter for the time-sharing (TS) service class. The NOS computer per- formance utility, CPD, can be helpful in determining the load profile for your system. We suggest you proceed with caution when tuning system performance; what seems obvious may lead not only to poorer performance, but a complex and confusing configuration. page 51 8 Network Management 8.1 Physical Sites Physical sites may be numbered from 0 to 62. The equipment connected to each site is determined by the configuration file. 8.1.1 Adding a New Physical Site A new physical site should be added to your network as follows: a. Change the configuration file network parameters to reflect the additional site(s). b. If the site being added is a NAM site (keyword "n1sit"), make sure that the 2550 can drive as many ports as NAM sites defined. The number of ports available on the 2550 can be changed by doing a partial build of CCP, which runs in the 2550. A description of that partial build process can be found in the PLATO Operations Guide and the NOS Installation Handbook. c. Bring up the application using the new configuration file. d. Lengthen the terminal location list as follows: 1. Execute lesson "ipedit". 2. Choose option to "Change length of terminal location list". 3. When asked the number of sites, enter the desired number and press NEXT. 4. Edit file "sites" and set terminal locations. e. Lengthen the ECS allotment tables as follows: 1. Execute lesson "ipedit". 2. Choose the option to "Change length of EM allotment tables". 3. When asked the number of sites, enter the desired number and press NEXT. 4. If desired, use the option in lesson "allocate" to assign the additional stations to any of the existing logical sites. f. Change file "s0netwk" so that it has a minimum of 18 * "nsite" records and "nsite" names. page 52 g. Lengthen "narfile" so that it contains at least "nsite" records. h. Update the network database as follows: 1. Execute lesson "pnet". 2. Press LAB for more editing options. 3. Choose the option to verify the database. 4. Press NEXT to start the verification. The routine will update the database as required. 8.3 PLATO-NAM Interface (PNI) The PLATO/NAM Interface program (PNI) directs the traffic between NAM and PLATO. NAM provides a simple interface to the network, but does not provide the type of interface required by PLATO. PNI will perform the functions required to interface NAM to PLATO. See the PLATO Operations Guide for more information about PNI. Key echo response time on PNI can be improved in terms of average and variability by making the frequently called NAM overlays CM/EM resident through LIBDECK entries. The appropriate overlays can be identified in the output produced from the NAM STATS package. page 53 9 System Network Management Some PLATO systems are linked together with communications links which allow the use of features such as inter-system general notes, personal notes and file transfers. Even without a link, a system may have an "authors" database for another system. In either case, a network system table entry must be maintained for all systems that are intended to be in the network. 9.1 Adding a System A system only needs to be added if the current system, and the new system, are both part of the linked system network, or if the "authors" database for a particular system is to be accessed. Use the following procedure to add a new system to the network system table. 9.1.1 Check for enough room in table First, you must check that your system is configured to allow adding another system to the network system table. a. Make sure that there is room in the network system table for another entry by checking the current number of systems in the table against the value of the "netms" configuration file keyword. Increase the value of the "netms" configuration file keyword if the limit has been reached. b. Use the following procedure to determine if you will need to lengthen common "link" of file "sysfile", which contains the network system table. 1. Edit file "sysfile". 2. Press "+" until you find the block named "link". 3. Press the letter which appears next to block "link" to edit it. 4. Near the top of the next display, you will see the current length of the common displayed. 5. If this length is greater than (1 + 10 * the value of the "netms" configuration file entry), you will not need to lengthen this common. c. If the current length of the common is too short, you should use the following procedure to lengthen it. 1. At a convenient time, back out all users. This is necessary to prevent a user from writing a common into file "sysfile" while the file is reorganized. page 54 2. Edit file "sysfile". 3. Press "+" until you find the block named "link". 4. Press the letter which appears next to block "link" to edit it. 5. Press SHIFT-LAB for "other options". 6. Choose the "change length of common" option. 7. Choose a new length which is the lowest multiple of 320 greater than (1 + 10 * the value of the "netms" configuration file entry). 9.1.2 Modify network configuration file If the new system is to be linked to your system through the PLATO Inter-system Link, you now need to modify your NOS communication network. If the new system is not to be linked to your system, continue with modifying the PLATO network system table. To establish a connection to another system, you need to define a path through NAM's network configuration file and RHP's logical identifier (LID) table. This procedure and other details about the installation and operation of these applications can be found in the following references: NOS Version 2 Feature Notes NOS Version 2 Installation Handbook (60459320) NOS Version 2 Analysis Handbook (60459300) Network Definition Language Reference Manual (60480000) Follow these steps: a. Update the LID configuration file. Refer to the the NOS Version 2 Analysis Handbook for examples. You will need to share this information with the admininstrators of the other system. b. Update your NDL file. Here are some examples of NDL entries you may need to make: * LINE definitions line: LINE,PORT=port,LTYPE=ltype,TIPTYPE=tiptype, PSN=psn,NSVC=svcric,DFL=dfl,FRAME=frame, RTIME=timer,RCOUNT=count,DCE=yn2. device: TERMDEV,STIP=stiptyp,NCIR=numcir,NEN=encir, DT=devtyp. * INCALL and OUTCALL statements for X.25 INCALL ANAME=ptfs,FAM=famname,UNAME=usernam, SNODE=srcnode,PORT=portnum,DNODE=dstnode, page 55 DBZ=dwnlsiz,UBZ=upbsize,DPLS=dpls. OUTCALL NAME1=ptfs,PID=pidname,SNODE=srcnode, DNODE=dstnode,PORT=portnum,DBZ=dwnlsiz, UBZ=ubpsize,DPLS=dpls,SHOST=srchost, DHOST=dsthost,DTEA=dtea. * INCALL and OUTCALL statements for shared 2550 INCALL ANAME=ptfs,FAM=famname,UNAME=usernam, DBL=dwnblim,ABL=abl. OUTCALL NAME1=ptfs,PID=pidname,SNODE=srcnode, DNODE=dstnode,DBL=dwnblim,ABL=abl. * INCALL and OUTCALL statements for direct line * or TRUNK INCALL ANAME=ptfs,FAM=famname,UNAME=usernam, SNODE=srcnode,PORT=portnum,DNODE=dstnode, DBZ=dwnlsiz,UBZ=upbsize,DPLS=dpls. OUTCALL NAME1=ptfs,PID=pidname,SNODE=srcnode, DNODE=dstnode,PORT=portnum,DBZ=dwnlsiz, UBZ=ubpsize,DPLS=dpls,SHOST=srchost, DHOST=dsthost. Refer to the NOS Version 2 Feature Notes for more examples. c. Build your new network configuration file and corresponding local configuration file using the NDLP system command. Refer to the Network Definition Language Reference Manual for examples. d. Bring down NAM, then reload NAM using the new configuration files and test your network. 9.1.3 Modify PLATO network system table You now need to update the PLATO Network System Table, which includes descriptions of the links between your system and other systems, and the options available to each link. Follow these steps: a. Sign on to PLATO with your "p" signon. b. Execute lesson "ipedit". c. Choose the "Network Management" option. d. Choose the "System Table" option. This takes you to the "Network System Table Management" display. e. Choose the "Add a new system to the table" option. f. Enter the name of the new system. This should be the same as the name specified by the "sid" PLATO configuration file keyword on that system. page 56 The next steps to be taken depend on if the system is not connected to your system through a link, the system is directly connected to your system through a link or the system is indirectly connected to your system through a link. A "directly connected" system is one which is linked to your system with no intermediate systems while an "indirectly connected" system is linked to your system through one or more intermediate systems. 9.1.3.1 Unconnected Systems If the system you are adding is not connected to your system through a link, follow these steps. Otherwise, continue with the next section. a. Choose the "Not linked to this system" option. b. On the next display, enter the routing identifier for the new system. This must be the same as the "rid" PLATO configuration file keyword on the new system. c. If there is to be an authors database file for the new system on your system, set the "authors database availablity" option to on. d. Continue with the "Final steps" section which follows. 9.1.3.2 Directly Connected Systems If the new system is directly connected through a 2550 link, use the following procedure. Most of the information you need to enter in the table will have to be provided to you by the administrators of the remote system. If the new system is not directly connected by a 2550 link, continue with the next section. a. Choose the "Directly connected by 2550 link" option. b. On the next display, choose the "Routing Identifier" option. The RID you enter must be the same as the "rid" PLATO configuration file keyword on the new system. c. Choose the "Link identifier:" option. Enter the logical identifier (LID) of the remote system (from your LID configuration file) and press NEXT. d. Choose the "Family name:" option. Enter the NOS family name to be used on the remote system and press NEXT. e. Choose the "User name password:" option. Enter the the user name password to be used on the remote system and press NEXT. f. Choose the "Charge number:" option. If the remote page 57 site will not be using NOS charge numbers, or, if they plan to use the default charge number they specified for the PLARECV/PLASEND user numbers, press NEXT. If they want to account for each remote system's usage, enter the charge number that was agreed upon by you and the remote sites administrator here. Refer to the "Link Accounting" section of this document for details. g. Choose the "Pack name:" option. Enter the pack name to be used on the remote system and press NEXT. h. Choose the "Pack type:" option. If you specified a pack name in the previous option, specify the pack type and press NEXT. The default is "dl". i. Choose the "Encryption key:" option. You and the administator of the remote system should decide upon a alphanumeric key of up to 7 characters that is used as the seed for encrypting files sent between your systems. This key is used only between your system and this particular remote system. You should have a different key for each remote system in your table. When you have decided upon a key, enter it and press NEXT. You should remind the remote system administrator to do the same for your system in his network table. j. Choose the "Encryption method:" option. Select "a. header only". (The option to encrypt the data being transfered is not available at this time.) k. Turn on the appropriate data transfer options. For instance, if you want to be able to send and receive pnotes, turn both these options on. You must also set the "Status of link with this system" option to on to allow any data transfers to take place. You can inhibit all data transfers by setting this one option to off. l. If there is to be an authors database file for the new system on your system, set the "authors database availability" option to on. m. Continue with the "Final steps" section which follows. 9.1.3.3 Indirectly Connected Systems If the new system is indirectly connected through a 2550 link, use the following procedure. Most of the information you need to enter in the table will have to be provided to you by the administrators of the remote system. a. Choose the "Indirectly connected through a 2550 link" option. page 58 b. On the next display, choose the "Routing Identifier" option. The RID you enter must be the same as the "rid" PLATO configuration file keyword on the new system. c. Choose the "First intermediate system:" option. Enter the name of the system that is the first node between your system and the remote system, and press NEXT. The name you enter should be the same as that specified by the "sid" PLATO configuration file keyword on the intermediate system. d. Choose the "Encryption key:" option. You and the administator of the remote system should decide upon a alphanumeric key of up to 7 characters that is used as the seed for encrypting files sent between your systems. This key is used only between your system and this particular remote system. You should have a different key for each remote system in your table. When you have decided upon a key, enter it and press NEXT. You should remind the remote system administrator to do the same for your system in his network table. e. Choose the "Encryption method:" option. Select "a. header only". (The option to encrypt the data being transfered is not available at this time.) f. Turn on the appropriate data transfer options. For instance, if you want to be able to send and receive pnotes, turn both these options on. You must also set the "Status of link with this system" option to on to allow any data transfers to take place. You can inhibit all data transfers by setting this one option to off. g. If there is to be an authors database file for the new system on your system, set the "authors database availability" option to on. h. Continue with the "Final steps" section which follows. 9.1.3.4 Final steps Once you have completed entering information required for the type of system being added, follow these steps. a. Press BACK to return to the "Network System Table Management" index. b. Choose the "Update the EM copy of the system table" option. Press SHIFT-HELP when requested. c. If the system is directly or indirectly connected via the PLATO inter-system link, run the "queue verification" system option in lesson "s0rhp". If errors occur, files "3netinq" and "3netoutq" may have page 59 to be lengthened. d. If there is to be an authors database for the new system, use the system options of lesson "authors" to add the new database. 9.2 Deleting a System A system may be removed from the network as follows: a. Use the "network management" option in lesson "ipedit" to delete the system from the network table. b. Use the option to "update the EM copy of the system table". c. Run the "queue verification" system option in lesson "s0rhp". When it pauses on an entry for a non- existent system, press SHIFT-HELP to delete it. d. If the system is directly or indirectly linked by a 2550 link, you must also remove it from your LID configuration file and NDL file. 9.3 Renaming a System Rename a system as follows: a. Use the "network management" options in "ipedit" to inspect the entry for the system to be renamed. Write down the current parameter settings. b. Delete the system from the table, but DO NOT run the verification options. c. Add a system with the new name and set all parameters to those you wrote down. d. Use the option to "update the EM copy of the system table". 9.4 Link Accounting The PLATO Inter-System Link has been designed to accomodate the standard NOS accounting mechanisms via charge and project numbers. At this time, there is no accounting within PLATO, so charges cannot be billed to a specific user, group or account. You have the option to use: 1) No charge and project number. In other words, no accounting at all. 2) Default charge and project numbers for user names PLASEND and PLARECV. This will give accounting for link traffic on your system as a whole. This page 60 will not show you from which remote systems the traffic is coming. 3) A charge number specified by you, with a project number for each remote system. This will give accounting for link traffic based on the originating system. Whatever option you choose, remote systems which connect to your system must have the corresponding information in their PLATO network system table. An error in charge information will inhibit link traffic until corrected. 9.4.1 No Charge/Project Numbers If you do not specify a charge number in either the PLATO network system table or as defaults for PLASEND/PLARECV, there will be no accounting for link traffic. The "charge number" option for your system in the PLATO network system table should be set to the default value. 9.4.2 Default Charge/Project Numbers When you specify default charge and project numbers for user names PLASEND and PLARECV, you will have a mechanism for accounting for link traffic on your system as a whole. This will show how much link traffic you have, but will not show from which remote system the traffic comes. 1) Set the default charge and project numbers for both PLASEND and PLARECV. This is done by using the MODVAL CN and PN parameters. We recommend that you use "PLATOLINK" as the default charge number for both user names. The default project numbers that you specify for the two user names may be different if you wish. 2) Set up the charge and project number you chose as defaults, using the NOS PROFILE command. Refer to the NOS Version 2 Administration Handbook for more information. 3) The "charge number" option for your system in the PLATO network system table should be set to the default value (*). 9.4.3 Charge Initiating System When you specify a charge number in your PLATO network system table and have remote systems specify a charge number for your system in their PLATO network system table, you will be able to account for traffic based on the originating system. 1) Use PROFILE to create a charge number for link traffic. We recommend the name "PLATOLINK". Then define the following project numbers: page 61 - one named "OVERHEAD" for link management jobs, - one named "UNKNOWN" for unidentified connections, - one for each remote system, using the system routing identifier (RID) as the name. 2) Use MODVAL to set the default charge and project numbers for user names PLASEND and PLARECV. Set the charge number to your specified charge number, and set the project number to "UNKNOWN". Connections using the default charge and project numbers will be accounted under this project number. The user numbers must also have the CNRD (charge not restricted to default) access word bit set. 3) Set the charge number for your system in the PLATO network system table. It is possible for remote systems to use more than one charge number, but link jobs submitted by your system will use the charge number specified in your system's entry in the PLATO network system table. Wherever possible, the RID of the system which initiated the traffic will be used as the project number for charges. The link management jobs which periodically check for in- coming requests will be charged to the "OVERHEAD" project number. Connections which do not specify a charge number will be charged to the "UNKNOWN" project number. page 62 20 ESM Management APPENDIX A EXTENDED SEMI-CONDUCTOR MEMORY MANAGEMENT page 63 20.1 ESM Management This section describes the management of Extended Semi- conductor Memory. Documentation of memory management within the PLATO application is described in the section on EM Management. The PLATO application, on 17x, or 170-700 series mainframes uses either ECS (Extended Core Storage) or ESM (Extended Semiconductor Memory) to store lesson material. The 800 series mainframes use UEM (Unified Extended Memory). This section is only applicable to systems which use ESM. The section on the "Low-speed port / DDP test program" is applicable to systems which use ESM or ECS. ESM may either run in ECS mode or in ESM mode. In either mode the side-door port is available and the error log maintained by the hardware is available. In ESM mode the following additional features are available: 1. addressing up to 16 million words 2. accessing the 16,384 extended flag registers 3. use of the relocation memory to flaw banks 20.2 Configuration file keywords The following PLATO configuration file keywords are used only on systems which use Extended Semiconductor Memory running in ESM mode. EFRB: extended flag register base The value of "efrb" is the base or first ESM flag register to use. This allows several jobs (possibly even multiple systems) to share the extended flag registers. The PLATO application uses 64 flag registers, starting with the base register. On systems without ESM, "efrb" should be omitted. On systems with ESM, the usual value of "efrb" is 64. Default value: 64 20.3 Program ESM This program is used to load ESM relocation memory, and to monitor and log errors. It is only used on systems which are using Extended Semi-conductor Memory. Many of the options of this program are used only if the memory is used in ESM mode. The control statement format is: page 64 ESM(nk) where: nk = NK, if you do not want to use the K-display. The program will roll out and periodicially roll in to update the disk copy of the error log. The K-display commands are listed below. All of the commands, except for "ERRORS", require that there be an ESM controller present, which is the case when running more than two million words of ESM. Command Description CLEAR. Clear the error logs. All single bit and double bit errors are removed from the ESM error log. CONFIG. Build a relocation memory that matches the ESM configuration. No programs should be using ESM when this option is used. END. Save the relocation memory and terminate job. The relocation memory is not loaded into ESM. ERRORS. Display the current copy of the ESM error logs. FLAW,bsu,bank. FLAW,bank. Toggle the flaw status of a bank. If no BSU is specified, BSU 0 is assumed. The relocation memory is sorted into bank order, placing all flawed banks at the end. GO. Save and load the relocation memory. Terminate program. HELP. Display the list of commands on the right screen. INIT. Initialize the relocation memory to 16 million words. When the relocation memory is over 8 million words, both the left and right screens are used to display the relocation memory. No programs should be using ESM when this option is used and no shared packs should be loaded in a multi-mainframe configuration. LOAD. Load relocation memory from file ESMRM under user SYSTEMX. MA,addr. Set "addr" as the highest logical address in use. No programs will be able to access past "addr". This extra memory may be used by Customer Engineering or may contain reserve or or flawed banks. page 65 PA,addr. Set "addr" as the highest physical entry in use in relocation memory. "addr" is the number of banks available - 1. RELOC. Display relocation memory. SAVE. Write relocation memory to file and save it for later loading. This file is called ESMRM and is defined under user SYSTEMX. STOP. Terminate program. SET,LA=addr,PA=addr. Set relocation entry "LA" to "PA". This option should only be used when specific relocation memory layout is required. ZERO. Write zeroes to all of ESM. This option can be useful in clearing errors. No programs should be accessing ESM when this option is used. When the relocation memory is displayed, the following symbols denote special status of a bank: * - not addressable f - flawed 20.3.2 Automatic Loading and Monitoring NOTE THE FOLLOWING SHOULD ONLY BE DONE IF THE ESM IS RUNNING IN ESM MODE. Prior to NOS 2.1, ESM error monitoring was only performed on PLATO systems by program ESM. Now, error monitoring can be performed by program ESM by using the SP EST entry to identify the ESM maintenance channel or by the system by identifying the ESM maintenance channel by using the "MC" parameter on the ESM EST entry ("DE"). See the NOS V2 Analysis Handbook for more information. The following is applicable only if ESM errorlog monitoring is done by program ESM. You can automatically load the relocation memory and monitor the error log by entering "X.ESM(NK)" at the console. To insure that this is run at all times, this entry is normally added as a DSD entry in the system IPRDECK. When ESM is first brought up with the NK option, it will load the relocation memory which has been previously saved and roll itself out. Every five minutes the program is rolled in again. It checks the error log for new entries and logs each message in the NOS error log and in dataset page 66 "s0esmerr" if it exists and is formatted correctly. NOS error log messages issued by ESM have the following format: ESM SNGL ERR,BSU1,BANK22,SCAN3,CS4,BIT55 CAB66,MODULE77-88,CHIPf99. ESM DBLE ERR,BSU1,BANK22,SCAN3,CS4,xxxxx CAB66,MODULE77-88. where: 1 = BSU number 22 = bank number 3 = scan number 4 = chip select number 55 = bit number (or MB if multiple bit error) 66 = cabinet name containing the board in error 77-88 = module name containing the board in error f99 = chip location on board xxxxx = 13 bits of address excluding BSU, bank, scan, and chip select Dataset "s0esmerr" also contains a log of the error messages. The dataset can be of any size. It is treated as a circular file. When an entry is written to the last slot in the file, the next entry is written to the first slot. The record size must be 320 words. The first record contains pointers to the next slot: Word 1 - 'esmerrs' (single quotes indicate right- justified, zero filled) Word 2 - record number to which next message is written. Initially, the record number should be 2. Word 3 - word number within record. Initially, the word number should be 1. Records 2 through the end of the file contain error log message prefaced by the date and time of entry. If a message does not fit in a record, the next record is used; messages do not span record boundaries. 20.3.3 Reloading the Memory NOTE THE FOLLOWING SHOULD ONLY BE DONE IF THE ESM IS RUNNING IN ESM MODE. The relocation memory must be loaded before NOS or the PLATO application may access ESM. Once the relocation memory is loaded, it only needs to be reloaded after: - power off - banks need to be flawed or unflawed - unusual hardware problem Normally, program ESM will automatically load the relocation memory when it first comes up. However, under certain page 67 conditions when the relocation memory has been destroyed or because the part NOS uses has been reconfigured, it will be necessary to load the relocation memory in the following manner: - Deadstart WITHOUT an ECS equipment (DE or DP) entry in the EQPDECK. - Enter "X.ESM(NK)." at the console (unless this is automatically done via an IPRDECK entry). - Re-deadstart in the normal manner. 20.3.4 Error Log Monitoring ESM hardware uses SECDED to detect and correct for memory errors whenever a single, double, or multiple-bit error occurs, and an entry is made in an error log maintained by the hardware. Program ESM monitors this error log and displays NOS error log message whenever a new entry is made. You can display these errors as follows: - Enter "X.ESM." at the console. - Assign the K display. - Enter "K.ERRORS." if the error display is not present. - enter "K.CLEAR." to clear the error log, if desired. - Enter "K.GO." when finished. 20.3.5 Flawing banks NOTE THE FOLLOWING SHOULD ONLY BE DONE IF THE ESM IS RUNNING IN ESM MODE. ESM banks may be logically flawed as follows: - Roll the ESM job in or initiate via "X.ESM." if it is not active. - Assign the K display. - Enter "K.RELOC." if the relocation display is not present. - Use "K.FLAW,bsu,bank." to toggle the flaw status of the appropriate banks. - Enter "K.GO." when all changes are made. 20.3.6 Changing ESM size Whenever you change ESM size, alter the configuration table page 68 as follows: - Redefine the ESM entry in the EQPDECK to use the new size. - After deadstarting, enter "X.ESM." at the console. Do NOT load the PLATO application software at this time. - Assign the K-display to the control point on request. - Use the entry "K.PA,rm" to set the maximum physical ESM memory address to use. - Use the entry "K.MA,rm" to set the maximum logical ESM memory address to use. - Enter "K.GO." at the console. - Change the "rax" and "flx" PLATO configuration file entries, if desired, and load the PLATO application. 20.4 Low-speed port / DDP test program The program DDPT is an on-line diagnostic program used to test a DDP or low-speed port concurrently with normal PLATO operations. See the PLATO Operations Guide for documentation of this program. page 69 21 Computer Interface Unit Network APPENDIX B COMPUTER INTERFACE UNIT NETWORK PARAMETERS page 70 21.1 EQPDECK entries The following describes EQPDECK entries needed to run the Computer Interface Unit Network. Note: CYBER 170-800 series mainframes do not support the CIU network. These parameters are used. ord = One- to three-digit octal Equipment Status Table (EST) ordinal of equipment st = (status) ON or OFF eq = (equipment) Controller number, which may vary with each system. The most commonly used number is shown. un = Unit number ch = Channel number to which the equipment is connected (ch0 or ch1 is used if two channel numbers are required) ic = Input channel oc = Output channel 1. CIU EQord=CI,ST=st,EQ=0,UN=un,CH=ic/oc. If the system has one CIU, set "un" to 0. If the system has two CIUs, set "un" to 0 for the first CIU and to 1 for the second CIU. 2. PIO low-speed port / DDP If the system has one CIU, use the following entry. EQord=D2,ST=st,EQ=5,UN=un,CH=ch. If the system has two CIUs, you must also have two low- speed port or DDP channels and use the following entry. EQord=D2,ST=st,EQ=5,UN=un,CH=ch0/ch1. 21.2 Configuration file keywords 21.2.1 Unique keywords The following keywords are only used on systems which have a Computer Interface Unit (CIU). C0SIT: first site on CIU 0 The value of "c0sit" is the number of the first site for which the CIU communication network is used. page 71 The usual value of "c0sit" is 0. Default value: 0 C1SIT: first site on CIU 1 The value of "c1sit" is the number of the first site to be used by a second CIU. The usual value of "c1sit" is 0 since most systems do not have a second CIU. Default value: 0 ETED: enhanced terminal error detection The value of "eted" is either ON or OFF depending on whether or not enhanced terminal error detection is enabled. When this is ON, a block checksum is sent as part of data sent to the terminal, and this checksum is used to detect errors and request re-transmission of bad data. When this parameter is OFF, only the single parity bit sent with each terminal word is used for error detection. The usual value of "eted" is ON. Default value: OFF FDLAY: frame delay for error correction For purposes of error correction, terminal output must be retained in EM for a long enough time to be sure that the output was received by the terminal without error. The parameter "fdlay" determines the minimum time that such output is retained. At 1200 baud, the standard "fdlay" of 45 is equivalent to retaining the output for 45/57 (approximately 3/4) of a second. If a system experiences longer echo times, then a larger value for "fdlay" must be used. The usual value for "fdlay" is 45. Default value: 45 FRAM1: CIU 0 frame length The value of "fram1" determines the size of the "frame" used to send output to CIU terminals on the first CIU. A frame contains one output word for each terminal for which output is pending. page 72 The usual value of "fram1" is: a. 50 for systems with less than 64 CIU users b. 100 for system with 64 - 128 CIU users c. 200 for systems with more than 128 CIU users Default value: 0 FRAM2: CIU1 frame length The value of "fram2" determines the size of the "frame" used to send output to CIU terminals on the second CIU. The usual value of "fram2" is 0, since most systems have only one CIU. If two CIUs are used, use the same values as given for "fram1". Default value: 0 IST3A: IST-III ASCII resident availability The value of "ist3a" is either ON or OFF depending on whether a user of an IST3 terminal may download the ASCII resident while on the CIU. The reason for having this parameter is to allow a user on the CIU to load the ASCII resident and then use some other ASCII feature such as the Interactive Access Facility (IAF). The usual value of "ist3a" is OFF. Default value: OFF IST31: IST-III resident 1 availability The value of "ist31" is either ON or OFF depending on whether resident 1 for the IST-III is available. This resident is a development version. The normal resident used is resident 0. The usual value of "ist31" is OFF. Default value: OFF NC0SI: number of sites on CIU0 The value of "nc0si" determines the number of sites connected to the first CIU. Default value: 0 NC1SI: number of sites on CIU 1 The value of "nc1si" determines the number of sites connected to the second CIU. Systems without a second page 73 CIU should set "nc1si" to 0. Default value: 0 21.2.1.1 Unique keywords (continued) PNET: network database (lesson "pnet") lockout The value of "pnet" determines if a check is to be made to insure that the network configuration for each terminal has been defined each time a user signs in. If the value of "pnet" is ON, when a user attempts to sign in on a terminal whose network configuration has not been defined in the network database maintained through lesson "pnet", access will not be allowed. This check is only made for terminals on the CIU network. The usual value of "pnet" is OFF. Default value: OFF 21.2.2 Changes to other keywords NAMPD: PLATO drop time The value of "nampd" is the time in seconds between the time the last user of PLATO through the ASCII network signs out and the time PNI drops the PLATO application. This feature should be used ONLY on PNI-only systems. On a system with both CIU and ASCII networks, if "nampd" is set to a non-zero number, users of PLATO through the CIU network could still be signed on when PLATO is dropped by PNI after the last ASCII network user signs out. Default value: 0 NSITE: number of physical sites On systems which use both the CIU and ASCII networks there are special considerations when setting the value of "nsite". All terminals will belong to a set of sites which are serviced by either the CIU network driver, PIO, or by the ASCII network driver, PNI. These sets of sites must include all sites (except possibly the runner site), and must not overlap. For example, the following is an acceptable configuration: nsite=13. thirteen physical sites on this system c0sit=0. CIU 0 network begins at site 0 page 74 nc0si=8. eight sites on CIU 0 nc1si=0. CIU 1 is not available n1sit=8. ASCII network starts at site 8 nn1si=4. four sites on ASCII network * note that site 12 is undefined so it may only * be used for runner terminals. 21.3 Runner programs These runner programs are used only on systems which have a CIU network and are optional. netmon: CIU network monitor cycle = 1 restart = 10 priority = 30 s0ciuru: collect CIU network performance statistics viewed through lesson "ciudiag" cycle = 20 restart = 5 priority = 30 page 75 22 Multi-mainframe APPENDIX C MULTI-MAINFRAME CONFIGURATIONS page 76 22.1 Multi-mainframe Considerations (Multi-mainframe features are not available for CYBER 170-800 series machines.) Several things should be kept in mind when configuring a multi-mainframe PLATO application. a. Multiple executors and formatters should be spread out over as many mainframes as possible. Since these programs are Central Processing Unit (CPU) bound, much more will be lost than gained if two of them end up contending for the same processor. This is especially true of formatters; two heavily loaded formatters will simply take over a machine, and leave little or no CPU time for anything else. b. CONDENSORs are disk bound. When the PLATO application is first loaded, and there is little for the executors and formatters to do, one machine can support up to three CONDENSORs reasonably well. Once the initial peak loads are past, extra CONDENSORs will be dropped and loaded automatically as needed. c. Essential equipment (disk controllers, CIUs, network devices, Extended Semiconductor Memory (ESM) side door ports, etc.) should be switchable between the usual primary mainframe and one other, in order to provide a backup in case the usual primary mainframe fails, or must be taken out of service for some reason. If every- thing is connected identically (same channels, etc.), it should be possible to switch primary mainframes simply by deadstarting with a different Machine Identifier (MID) and switching non-shared devices over to the alternate mainframe. The "mford" configuration file entry would also have to change and file LCONFIG would have to be removed to identify the backup system as the primary mainframe. 22.2 The "config" File Each mainframe in the configuration must have its own copy of the configuration file. It is likely there will be slight differences in the configuration file for each mainframe. In some cases, such differences are mandatory. The basic configuration file can still be shared between all mainframes and the keywords which must be different can be placed in the file LCONFIG to override the matching ones in the basic configuration file. LCONFIG serves two purposes. It allows this replacing of configuration parameters and it identifies the mainframe as a secondary one by its presence. LCONFIG is placed in the the permanent file catalog of NOS user name PLATOMF (user index 377773b). page 77 22.2.1 Changes for Mainframe 0 When adding a mainframe, the following parameters MUST be changed on the primary mainframe (mainframe 0). nmf must be set to the new number of mainframes Other parameters which are likely to change when adding additional executors, CONDENSORs, etc.: ncond nexec nfmtr If you are expanding your system size (EM size, disk, network, etc.) at the same time, review all configuration file entries to see if they need to be changed. 22.2.2 Keywords required for all mainframes The keywords in this section must be included in the configuration file for every mainframe in a multi-mainframe environment. They are the only parameters required for any mainframe which will not be running an executor. The parameters below must be the same on all mainframes: flx njob rax subun The parameters below are required on all mainframes, but each mainframe may use its own setting: famly mford mmf passw secur syot 22.2.3 Keywords required for executors On any mainframe which is running an executor, all keywords in the configuration file must be the same with the exception of those listed in the previous section and those listed below: cpspd 22.3 Configuration file keywords 22.3.1 Unique keywords The following configuration file keywords are used only on systems which are running the PLATO application in a multi- page 78 mainframe configuration. MFORD: mainframe ordinal The value of "mford" determines the mainframe ordinal. The primary mainframe uses the value 0 and secondary mainframes use a value greater than 0 but less than "nmf". Default value: 0 MMF: jobs on this mainframe The value of "mmf" is either ON or OFF depending on whether the PLATO application may use this mainframe for application related jobs (executors, CONDENSORs, etc.). If it is set to OFF, the second mainframe is only available for batch jobs. The usual value for "mmf" is ON. Default value: ON NEXEC: number of executors The value of "nexec" determines the number of PLATO executors to be run on all mainframes. The distribution of these executors over the different mainframes is up to the site. If more than one executor is available, users will be automatically distributed to the different executors in a manner that attempts to even out the load. The value of "nexec" must be less than or equal to 3. Default value: 1 NFMTR: number of formatters The value of "nfmtr" determines the number of formatters to be run on all mainframes. The distribution of the formatters is up to the site. If the value of "nfmtr" is 2, a FORMAT will be run in addition to FRAMAT. The formatters always remain at control points. This option should not be needed except on heavily-loaded multi-mainframe systems. systems. The value of "nfmtr" must be either 1 or 2. Default value: 1 page 79 NMF: number of mainframes The value of "nmf" determines the number of mainframes available for the submission of batch jobs or for the PLATO application jobs. Most systems have only a single mainframe, so "nmf" is usually set to 1. If "nmf" is greater than 1, the parameter "bgecs" may have to be increased because of the extra extended memory used by MASTORN. Default value: 1 22.3.2 Changes to other keywords The following configuration file keywords may have different meanings in a multi-mainframe configuration. See the main section on the "PLATO Configuration File" for more information on each of these keywords. NAM: PLATO-NAM Interface (PNI) availability The value of "nam" is set to the number of copies of NAM and PNI running on a system when the ASCII network is in use for PLATO. On systems which do not use the ASCII network for PLATO, the value of "nam" must be set to 0. On single-main- frame systems which use the ASCII network for PLATO, the value of "nam" must be 1. On multi-mainframe systems, the maximum value of "nam" must be less than or equal to 3. Default value: 1 NN1SI: number of NAM (PNI) sites The value of "nn1si" determines the number of PLATO sites (groups of 32 terminals) for use with the ASCII network. If running in a multi-mainframe configuration with more than one copy of NAM and PNI, this keyword determines the number of PLATO sites assigned to the PNI with the ordinal 1, while "nn2si" determines the number of PLATO sites assigned to the PNI with ordinal 2, etc. Default value: 2 NSITE: number of physical sites When running with more than one copy of NAM and PNI in a multi-mainframe configuration with sites assigned to each copy of PNI, the sets of sites must include all sites defined by the value of "nsite" with the exception page 80 of the highest site which is used by the runner programs and all sets of sites must be contiguous with no overlap. The following is a valid configuration: nsite=7. n1sit=0. PNI 1 sites begin at 0 nn1si=4. for four sites n2sit=4. PNI 2 sites begin at 4 nn2si=2. for two sites * note that site 6 is undefined so it may only * be used for runner terminals. N1SIT: first NAM (PNI) site The value of "nn1si" determines the number of PLATO sites allocated. Each site may be used by up to 32 terminals. If running in a multi-mainframe configuration with more than one copy of NAM and PNI, this keyword determines the number of PLATO sites assigned to the PNI with the ordinal 1, while "nn2si" determines the number of PLATO sites assigned to the PNI with ordinal 2, etc. SECUR: application security level The value of "secur" is either ON or OFF depending on the desired security level. It is mainframe dependent, so each mainframe in a multi-mainframe system may use a different value. When set to ON, system lessons are prevented from accessing information for a mainframe. For example, if the value of "secur" is ON, no console displays may be seen via lesson "console". SYOT: system origin permission The value of "syot" can be different on each mainframe. The value of "syot" must be greater than 0 on any main- frame which is to run a PLATO executor so that utilities such as "ldr" will work correctly. 22.4 System lesson parameters An option in lesson "ipedit" can be used to determine on which mainframes additional CONDENSORs will be submitted when they are required. Another option in lesson "ipedit" is used to edit a list of mainframe to which jobs may be submitted. See the section on "System Lesson Parameters" in this Handbook. page 81 22.5 LIBDECK Changes When additional PLATO executors are to be run, the following entry must be added to the LIBDECK: *proc exec page 82 70 Release Changes RELEASE CHANGES page 83 70.1 Release Changes The following changes have been made to the PLATO Configuration Handbook for the current release. TOPIC SECTION CHANGE DELETE ADD Editorial changes made page 84 80 Index INDEX page 85 ALPHABETICAL CROSS-REFERENCE INDEX This index supplements the Table of Contents. Items will be found in alphabetical order. Entries beginning with a number follow "z" and entries with a number as the second character will be found at the end of that alphabetical list. page 86 80.1 Index: A - B acclog0 ....................................... 3.2.6 ACCOUNT EQPDECK entry ......................... 2.2 account log (see "NOS account log") adding a required master file ................. 6.2.2 adjusting EM allocation ....................... 5.3.2 allocate ...................................... 5.2 5.3.2 8.1 allocating EM ................................. 5.3 archive recycle period ........................ 4 author mode display ........................... 4.1 authors ....................................... 3.2.6.1 3.2.8 3.2.9 9.2 9.2.1 BACKDMP LIBDECK entry ......................... 2.3 BACKMOD ....................................... 6.2.2 6.2.3 batch jobs .................................... 3.2.1 3.2.1 3.2.6.1 3.2.7 3.2.9 batch submission control ...................... 4 "bgecs" ....................................... 3.1 3.2.1 22.3.1 "bgpct" ....................................... 3.1 3.2.1 binary ........................................ 6.3 BKSTART LIBDECK entry ......................... 2.3 80.2 Index: C - D "cblth" ....................................... 3.1 3.2.2 -cdate- TUTOR command ......................... 3.2.3 "cdisk" ....................................... 3.1 3.2.2 3.2.6.1 central processor speed ....................... 3.2.2.1 changing a required master file ............... 6.2.3 CI EQPDECK entry .............................. 21.1 CIU ........................................... 3.2.6 21.1 21.2.1 21.2.2 22.1 22.3 ciudiag ....................................... 22.3 CM data transfer path ......................... 2.2.1 page 87 3.2.6.1 6.1.1 "cmp" ......................................... 3.1 3.2.2 CMRDECK ....................................... 2.1 CONDENSOR ..................................... 3.2.2 3.2.2.1 3.2.5 3.2.6.1 4.1 7.3 22.1 22.3.1 22.4 CONDENSOR statistics .......................... 3.2.2.1 CONDX LIBDECK entry ........................... 2.3 configuration file (see "PLATO configuration file") CONFIGX LIBDECK entry ......................... 2.3 "confr" ....................................... 3.1 3.2.2 console ....................................... 3.2.9 22.3.2 continuous polling ............................ 4 COPYPD LIBDECK entry .......................... 2.3 "cpspd" ....................................... 3.1 3.2.2.1 7.2 22.2.3 CPU priority .................................. 7.3 "cshar" ....................................... 3.1 3.2.2.1 7.3 "cstat" ....................................... 3.1 3.2.2.1 -ctime- TUTOR command ......................... 3.2.10 "c0sit" ....................................... 21.2.1 "c1sit" ....................................... 21.2.1 "datef" ....................................... 3.1 3.2.3 dayfile (see "NOS dayfile") DAYFILE EQPDECK entry ......................... 2.2 DDP (see "low-speed port") DELAY IPRDECK entry ........................... 2.4 DUMPPRT LIBDECK entry ......................... 2.3 D1 EQPDECK entry .............................. 2.2.1 3.2.6.1 6.1.1 D2 EQPDECK entry .............................. 21.1 80.3 Index: E "edel1" ....................................... 3.1 3.2.3 5.3.4 "edel2" ....................................... 3.1 page 88 3.2.3 5.3.4 "edel3" ....................................... 3.1 3.2.3 5.3.4 "efrb" ........................................ 20.2 EM allocation table ........................... 4.1 8.1 EM deletion ................................... 3.2.3 3.2.9 5.3.2 5.3.4 EM manager .................................... 3.2.3 5.1 5.4 5.4.1 5.4.2 5.4.3 EMDTAPE LIBDECK entry ......................... 2.3 "emgr1" ....................................... 3.1 3.2.3 5.4 5.4.1 "emgr2" ....................................... 3.1 3.2.3 5.4 5.4.3 "emgr3" ....................................... 3.1 3.2.3 5.4 5.4.1 "emgr4" ....................................... 3.1 3.2.3 5.4 5.4.1 EMPRT LIBDECK entry ........................... 2.3 ENABLE IPRDECK entry .......................... 2.4 ENDOFBC LIBDECK entry ......................... 2.3 enforcer ...................................... 5.3.3 EQPDECK ....................................... 2.2 2.2.1 3.2.6.1 6.2.2 6.2.3 21.1 ERRLOG EQPDECK entry .......................... 2.2 error log (see "NOS error log") ESM (see also "program ESM") .............. 2.2.1 2.4 3.2.1 3.2.8 6.1.1 20.1 ESM error monitoring .......................... 2.2.1 20.3 20.3.2 20.3.4 page 89 ESM flawing ................................... 20.3.5 ESM IPRDECK entry ............................. 2.4 20.3.2 ESM maintenance channel ....................... 2.2.1 ESM size ...................................... 20.3.6 "estat" ....................................... 3.1 3.2.3 "eted" ........................................ 21.2.1 execution statistics .......................... 3.2.3 executor (see "PLATO executor") 80.4 Index: F - L family (see "NOS family") "famly" ....................................... 3.1 3.2.4 22.2.2 "fastl" ....................................... 3.1 3.2.4 "fdlay" ....................................... 21.2.1 file management log ........................... 3.2.6 "flx" ......................................... 2.2 3.1 3.2.4 3.2.8 20.3.6 22.2.2 "fofrl" ....................................... 3.1 3.2.4 FORMCMD LIBDECK entry ......................... 2.3 "forml" ....................................... 3.1 3.2.4 FRAMAT ........................................ 3.2.4 3.2.6.2 22.1 22.3.1 FRAMX LIBDECK entry ........................... 2.3 "fram1" ....................................... 21.2.1 "fram2" ....................................... 21.2.1 group "coserv" ................................ 3.2.9 group "s" ..................................... 3.2.9 installation mode ............................. 3.2.5 "instl" ....................................... 3.1 3.2.5 ipedit ........................................ 4 6.2.2 6.2.3 9.1 9.2.1 9.2.2 9.2.3 22.4 IPRDECK ....................................... 2.4 page 90 20.3.2 "ist3a" ....................................... 21.2.1 "ist31" ....................................... 21.2.1 "jbnks" ....................................... 3.1 3.2.5 judge buffers ................................. 3.2.5 keyword definitions ........................... 3.2 keyword types ................................. 3.1 ldr ........................................... 3.2.9 22.3.2 LCONFIG ....................................... 22.1 22.2 "lesns" ....................................... 3.1 3.2.5 5.4.1 lesson buffer ................................. 3.2.5 5.1 5.3 5.4 5.4.1 5.4.2 5.4.3 lesson "pnet" ................................. 4 8.1 21.2.1.1 lesson "site" ................................. 3.2.9 5.3.2 5.3.4 lesson "sites" ................................ 8.1.1 LIBDECK ....................................... 2.3 8.3 22.5 logical site .................................. 3.2.6.2 5.2 5.3.3 5.3.4 low-speed port ................................ 2.2.1 3.2.6.1 3.2.7 6.1.1 20.1 20.4 80.5 Index: M MAINLOG EQPDECK entry ......................... 2.2 maintenance log (see "NOS maintenance log") MAS LIBDECK entry ............................. 2.3 master file ................................... 3.2.6.1 3.2.7 4 page 91 6.1 6.2.1 6.2.2 6.2.3 6.3 MASTOR ........................................ 2.2.1 2.4 6.1.1 "mcond" ....................................... 3.1 3.2.5 MFCREAT ....................................... 6.1 6.2.2 MFDX .......................................... 6.2.2 6.2.3 MFDX LIBDECK entry ............................ 2.3 MFNX .......................................... 6.2.2 6.2.3 MFNX LIBDECK entry ............................ 2.3 "mford" ....................................... 22.1 22.2.2 22.3.1 MFPACK LIBDECK entry .......................... 2.3 MFTCOPY LIBDECK entry ......................... 2.3 MFTLOAD LIBDECK entry ......................... 2.3 "mmf" ......................................... 22.2.2 22.3.1 MRQ LIBDECK entry ............................. 2.3 multi-mainframe ............................... 3.2.5 22.1 MXX ........................................... 2.2 80.6 Index: N "nacnt" ....................................... 3.1 3.2.6 "nalog" ....................................... 3.1 3.2.6 "nam" ......................................... 3.1 3.2.6 22.3.2 "nampd" ....................................... 3.1 3.2.6 21.2.2 "namto" ....................................... 3.1 3.2.6 narfile ....................................... 8.1 "ncmb" ........................................ 2.2.1 3.1 3.2.6.1 6.1.1 "ncond" ....................................... 3.1 3.2.2 3.2.6.1 22.2.1 "nc0si" ....................................... 21.2.1 "nc1si" ....................................... 21.2.1 "ndsus" ....................................... 3.1 page 92 3.2.6.1 6.2.1 6.2.2 netmon ........................................ 22.3 "netms" ....................................... 3.1 3.2.6.1 9.2.1 network database .............................. 3.2.7 4 network management ............................ 4 network system table .......................... 3.2.6.1 4 9.2 "nexec" ....................................... 22.2.1 22.3.1 80.6.1 Index: NF "nfmtr" ....................................... 22.2.1 22.3.1 "niob" ........................................ 3.1 3.2.6.1 "njob" ........................................ 3.1 3.2.6.1 22.2.2 "nmf" ......................................... 22.2.1 22.3.1 "nn1si" ....................................... 3.1 3.2.6.2 3.2.6.3 22.3.2 NOS account log ............................... 2.2 5.3.4 NOS dayfile ................................... 2.2 NOS error log ................................. 2.2 20.3.2 NOS family .................................... 3.2.4 NOS maintenance log ........................... 2.2 NOS password .................................. 3.2.7 NOS user name ................................. 3.2.7 3.2.9 22.2 "nparc" ....................................... 3.1 3.2.6.2 "npms" ........................................ 3.1 3.2.6.1 3.2.6.2 6.1.1 "nrunr" ....................................... 3.1 3.2.6.2 "nsite" ....................................... 3.1 3.2.6.3 8.1 21.2.2 22.3.2 "n1sit" ....................................... 3.1 3.2.6.3 page 93 8.1 22.3.2 80.7 Index: O - P operator ...................................... 6.2.1 operator station .............................. 4 PAFTERM LIBDECK entry ......................... 2.3 parcels ....................................... 3.2.6.2 "passw" ....................................... 3.1 3.2.7 22.2.2 password time limit ........................... 3.2.7 PCDCONV LIBDECK entry ......................... 2.3 PDCAT LIBDECK entry ........................... 2.3 physical site ................................. 3.2.6.3 PIO ........................................... 21.1 21.2.2 PLAINS. DSD-command ........................... 3.2.5 PLATO account ................................. 3.2.6 PLATO configuration file ...................... 2.2.1 3 entry format .............................. 3 keyword definitions ....................... 3.2 keyword types ............................. 3.1 PLATO. DSD-command ............................ 2.4 PLATO executor ................................ 22.1 22.2.3 22.3.1 22.3.2 22.5 PLATO Installation Guide ...................... 1 PLATO Inter-system Link ....................... 3.2.6.1 3.2.8 3.2.9 9 PLATO Operations Guide ........................ 1 2.3 3.2.6.2 4.1 6.2.2 6.2.3 8.1 PLATO User's Guide ............................ 1 PLATOD ........................................ 3.2.9 PLATOMF ....................................... 22.2 PLATX LIBDECK entry ........................... 2.3 PLAUPD. DSD-command ........................... 3.2.5 PMS ........................................... 2.2.1 3.2.6.1 3.2.6.2 6.1 PMS LIBDECK entry ............................. 2.3 "pnet" (see also "lesson pnet") ........... 21.2.1.1 PNET lockout message .......................... 4 page 94 21.2.1.1 PNI ........................................... 2.4 3.2.6 3.2.6.2 3.2.6.3 8.3 21.2.2 22.3.2 PNIX LIBDECK entry ............................ 2.3 preferred language table ...................... 4.1 prime-time table .............................. 4 prints ........................................ 3.2.7 program ESM ................................... 20.3 20.3.2 20.3.3 ESM K-display ............................. 20.3 20.3.3 20.3.4 20.3.5 20.3.6 "prtun" ....................................... 3.1 3.2.7 ptime ......................................... 4 "ptlim" ....................................... 3.1 3.2.7 "pwbot" ....................................... 3.1 3.2.7 "pwnot" ....................................... 3.1 3.2.7 "pwoff" ....................................... 3.1 3.2.7 80.8 Index: Q - R queue size .................................... 3.2.7 "quesz" ....................................... 3.1 3.2.7 RAFPDD ....................................... 5.3.2 "rax" ......................................... 2.2.1 3.1 3.2.4 3.2.8 20.3.6 22.2.2 RECOVAL LIBDECK entry ......................... 2.3 RECOVMF LIBDECK entry ......................... 2.3 relocation memory ............................. 2.4 20.3 20.3.2 20.3.3 required master file table .................... 4 restrict system personnel access .............. 4 "rid" ......................................... 3.1 3.2.8 routing ID .................................... 3.2.8 page 95 runner programs ............................... 3.2.6.2 3.2.6.3 5.3.3 21.2.2 21.3 22.3.2 80.9 Index: S - Z "secur" ....................................... 3.1 3.2.9 22.2.2 22.3.2 security level ................................ 3.2.7 3.2.9 services available time table ................. 4 SETPUN LIBDECK entry .......................... 2.3 shared low-speed port/DDP ..................... 2.2.1 6.1.1 "sid" ......................................... 3.1 3.2.9 side-door port ................................ 2.2.1 22.1 signon display ................................ 4 site (see "logical site", "physical site", "lesson "site"", "lesson "sites"") SP EQPDECK entry .............................. 2.2.1 20.3.2 special station list .......................... 4 stats ......................................... 5.3.2 "subun" ....................................... 3.1 22.2.2 "syot" ........................................ 3.1 3.2.9 22.2.2 22.3.2 "sysac" ....................................... 3.1 3.2.9 4 "sysdl" ....................................... 3.1 3.2.9 5.3.4 sysfile ....................................... 9.2.1 system account log (see "NOS account log") system dayfile (see "NOS dayfile") system error log (see "NOS error log") system ID ..................................... 3.2.9 system lesson access lists .................... 4 system maintenance log (see "NOS maintenance log") system1 ....................................... 3.2.2.1 3.2.3 4.1 5.3.1 5.3.2 7.1 s0calutil ..................................... 4 s0ciudiag ..................................... 21.3 page 96 s0confer ...................................... 3.2.2 s0config ...................................... 5.3.1 s0cpspd ....................................... 7.2 s0cpudata ..................................... 7.1 s0cpustat ..................................... 7.1 s0esmerr ...................................... 20.3.2 s0netwk ....................................... 8.1 s0rhp ......................................... 9.2.1 9.2.2 s0sysmsg ...................................... 3.2.7 tele-conferencing (see "confr") terminal location list ........................ 4.1 8.1 TERM-confer (see "confr") THRESHOLD EQPDECK entry ....................... 2.2 time zone ..................................... 4 "timef" ....................................... 3.1 3.2.10 transfer path (see "CM data transfer path") TUTOR command statistics ...................... 3.2.2.1 3.2.3 update level table ............................ 4.1 "users" ....................................... 3.1 3.2.5 3.2.6.3 VERSX LIBDECK entry ........................... 2.3 Welcome to PLATO message ...................... 4 zlang ......................................... 4.1 zsystem ....................................... 3.2.9 Table of Contents 1 Introduction 1 2 Deadstart File 2 2.1 CMRDECKs 3 2.2 EQPDECKs 4 2.2.1 EQPDECKs 5 2.3 LIBDECKs 7 2.4 IPRDECKs 8 3 The PLATO Configuration File 10 3.1 Types of Keywords 11 3.2 Keyword Definitions 14 3.2.1 Keywords: A - B 15 3.2.2 Keywords: CA - CO 15 3.2.2.1 Keywords: CP - CZ 16 3.2.3 Keywords: D - E 18 3.2.4 Keywords: F 20 3.2.5 Keywords: G - M 21 3.2.6 Keywords: NA - NB 23 3.2.6.1 Keywords: NC - NM 24 3.2.6.2 Keywords: NN - NR 26 3.2.6.3 Keywords: NS - NZ 27 3.2.7 Keywords: O - Q 28 3.2.8 Keywords: R 30 3.2.9 Keywords: S 30 3.2.10 Keywords: T - Z 32 4 System Lesson Parameters 34 4.1 35 5 EM Management 37 5.1 The Lesson Buffer 37 5.2 Logical Sites 37 5.3 Allocateable EM 37 5.3.1 How Much to Allocate 38 5.3.2 Adjusting the Allocations 38 5.3.3 Actions to Correct Memory Shortages 39 5.3.4 Controlling EM Deletions 40 5.4 EM Manager Parameters 40 5.4.1 Search Phase 41 5.4.2 Delete Phase 42 5.4.3 Compaction Phase 42 6 Disk System Management 44 6.1 Setting Up Your Disk System 44 6.1.1 Setting Up Your Disk (continued) 45 6.2 User File Space Management 46 6.2.1 File Space Monitoring 46 6.2.2 Adding a Required Master File 46 6.2.3 Changing a Required Master File 47 6.3 Binary File Space Management 47 7 CPU Usage Management 49 7.1 Statistics Collection 49 7.2 Adjusting "cpspd" 49 7.3 Adjusting "cshar" 49 8 Network Management 51 8.1 Physical Sites 51 8.1.1 Adding a New Physical Site 51 8.3 PLATO-NAM Interface (PNI) 52 9 System Network Management 53 9.1 Adding a System 53 9.1.1 Check for enough room in table 53 9.1.2 Modify network configuration file 54 9.1.3 Modify PLATO network system table 55 9.1.3.1 Unconnected Systems 56 9.1.3.2 Directly Connected Systems 56 9.1.3.3 Indirectly Connected Systems 57 9.1.3.4 Final steps 58 9.2 Deleting a System 59 9.3 Renaming a System 59 9.4 Link Accounting 59 9.4.1 No Charge/Project Numbers 60 9.4.2 Default Charge/Project Numbers 60 9.4.3 Charge Initiating System 60 20 ESM Management 62 20.1 ESM Management 63 20.2 Configuration file keywords 63 20.3 Program ESM 63 20.3.2 Automatic Loading and Monitoring 65 20.3.3 Reloading the Memory 66 20.3.4 Error Log Monitoring 67 20.3.5 Flawing banks 67 20.3.6 Changing ESM size 67 20.4 Low-speed port / DDP test program 68 21 Computer Interface Unit Network 69 21.1 EQPDECK entries 70 21.2 Configuration file keywords 70 21.2.1 Unique keywords 70 21.2.1.1 Unique keywords (continued) 73 21.2.2 Changes to other keywords 73 21.3 Runner programs 74 22 Multi-mainframe 75 22.1 Multi-mainframe Considerations 76 22.2 The "config" File 76 22.2.1 Changes for Mainframe 0 77 22.2.2 Keywords required for all mainframes 77 22.2.3 Keywords required for executors 77 22.3 Configuration file keywords 77 22.3.1 Unique keywords 77 22.3.2 Changes to other keywords 79 22.4 System lesson parameters 80 22.5 LIBDECK Changes 81 70 Release Changes 82 70.1 Release Changes 83 80 Index 84 80.1 Index: A - B 86 80.2 Index: C - D 86 80.3 Index: E 87 80.4 Index: F - L 89 80.5 Index: M 90 80.6 Index: N 91 80.6.1 Index: NF 92 80.7 Index: O - P 93 80.8 Index: Q - R 94 80.9 Index: S - Z 95 full dayfile. 97/11/05. 06.00.46.*06.00.38* page 1 06.00.38.admi. 06.00.38.user,prints,,systfa. admin3,s 06.00.38.absc, s. 06.00.38.masjob,input,ss. 06.00.38.pf(pb,print,z,z),mods/prtsub,upperlower 06.00.38.note(param,nr)/77777777777777777777 06.00.38.note(param,nr)/77777777777777777777 06.00.38.pack,param. 06.00.38. pack complete. 06.00.38.note(printit,nr)/.proc,printit. 06.00.38.note(printit,nr)/docprt.pcguide,system,s,admin3 06.00.38.note(printit,nr)/* 06.00.38.pack(printit) 06.00.38. pack complete. 06.00.38.block,output.*cybis file*pcguide*admin3**s* 06.00.39.print(p0=,p1=$$,p2=$$,p3=$$) 06.00.39.setpr(30) 06.00.39.settl(7777) 06.00.39. tl = 7777. 06.00.39.*route,output,dc=pr,ic=bin,fc=as,def. 06.00.39.printit. 06.00.39.docprt.pcguide,system,s,admin3 06.00.46. stop 06.00.46. 043700 maximum execution fl. 06.00.46. 1.035 cp seconds execution time. 06.00.46.* 06.00.46.$revert.ccl 06.00.46.dayfile. 06.00.56.UCLP, OK, 030, 6.592KLNS.